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

← →
Дмитрий С © (2011-08-18 23:08) [0]

Немного поискал в сети, даже поставил себе, так и не понял - это версия в ширь или в рост?

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

← →
Inovet © (2011-08-18 23:23) [1]

Что-то поздно ты проснулся.:)

← →
DVM © (2011-08-18 23:31) [2]

> Дмитрий С © (18.08.11 23:08)

> Мне показалось что у нее некоторые проблемы в юникодом

нет у нее никаких проблем с юникодом. Шрифт выбери нормальный.

← →
Дмитрий С © (2011-08-18 23:38) [3]

> DVM © (18.08.11 23:31) [2]

Так не дает нормальный выбирать:( У меня на работе 2010 стоит - там можно нормально выбрать, например, Arial - он и будет нормально отображаться, а тут не хочет. Можно установить чтото вроде @Arial - будет показывать японский, но остальные (английские и русские) показывает плохо (шрифт явно не Arial). Конечно может это и не с дельфи связано.

← →
Игорь Шевченко © (2011-08-18 23:53) [4]

поддержку азиатских языков установи, а потом говори про проблемы у XE

← →
Дмитрий С © (2011-08-19 00:05) [5]

> Игорь Шевченко © (18.08.11 23:53) [4]

Точно, помню что-то такое было в XP, а в 7ке не нашел как доставить. Сейчас еще поищу.

← →
Дмитрий С © (2011-08-19 00:10) [6]

Хотя бразуер, да и остальная Windows спокойно отображает японские символы.
Только что создал файл トヨタ自動車.txt с таким же содержанием. Explorer и notepad свободно его отображают

← →
Дмитрий С © (2011-08-19 00:29) [7]

Ха, удивительно. Заработал японский. Вместо квадратов теперь японские буквы. Хотя я ничего не делал.

Как я понял XE это просто новая 2011 версия delphi да?

← →
Германн © (2011-08-19 01:08) [8]

> Дмитрий С © (18.08.11 23:08)
>
> Немного поискал в сети, даже поставил себе

Ну и зачем поставил?

← →
Кто б сомневался © (2011-08-19 02:06) [9]

Сразу скажи с какой версии переходил.

← →
Дмитрий С © (2011-08-19 02:10) [10]

На работе стоит 2010 - с нее и переходил.

А поставил на свой нетбук - надо было одну програмку написать, для локализации одной игрушки:)

← →
Anatoly Podgoretsky © (2011-08-19 09:15) [11]

> Дмитрий С (19.08.2011 00:29:07) [7]

Барабашка?

← →
Anatoly Podgoretsky © (2011-08-19 09:15) [12]

> Дмитрий С (19.08.2011 02:10:10) [10]

И зря, 2010 ничем не хуже

← →
uw © (2011-08-19 17:57) [13]

Anatoly Podgoretsky © (19.08.11 09:15) [12]
И зря, 2010 ничем не хуже

Помнится, заводил я тут тему о том, что в 2010 при создании диалога меняется раскладка с русской на латиницу. В 2006 всё было нормально, а в 2010 - фигня. Не для всех программ, а вот для моей конкретной. Мне ещё тогда ИШ посоветовал проверять результат, возвращаемый функцией API. Ну это не помогло, конечно :) Как я ни вертелся, 2010 так нормально и не заработала. Пришлось мне этот проект сопровождать в 2006.

А тут Толя со своим заявлением, де, ничем не хуже. Дай, думаю, попробую на ХЕ. Попробовал - и получилось! Теперь можно от 2006 избавляться.

Так что, и от Подгорецкого иногда толк бывает!

← →
Anatoly Podgoretsky © (2011-08-19 18:05) [14]

> uw (19.08.2011 17:57:13) [13]

Не торопись избавляться.

← →
uw © (2011-08-19 18:13) [15]

Не буду. У нас есть ещё проект, в который я время от времени вставляю что-то. Проект большой и написан на 2006-м. Парень, который ведёт этот проект, не видит возможности перейти на следующие версии. Поэтому и я на всякий случай тестирую свои вставки на 2006-м.

← →
Eraser © (2011-08-19 19:36) [16]

> [15] uw © (19.08.11 18:13)

> Парень, который ведёт этот проект, не видит возможности
> перейти на следующие версии

лентяй парень, гнать из конторы.

← →
Игорь Шевченко © (2011-08-19 20:34) [17]

> лентяй парень, гнать из конторы.

На свете бывают проекты посложнее Hello, world, на перевод которых требуются трудозатраты, которые нафиг никому не сдалось оплачивать. Расширяй кругозор, дружище, и не ставь диагнозов, не думая.

← →
DVM © (2011-08-19 22:27) [18]

> Игорь Шевченко © (19.08.11 20:34) [17]

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

Трудозатраты на перевод любого проекта под Delphi XE не такие уж большие, если все самописное. На первом этапе можно обойтись глобальным поиском и заменой. А грамотно написанные проекты вообще переводить не требуется. Так что еще проблемы с переводом - это результат халатного отношения к работе ранее. Года с 2000 талдычат, не надо рассчитывать, что размер Char не изменится. Года с 2006 талдычат, что Pointer нельзя приводить к Integer и ноборот.

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

DVM © (19.08.11 22:27) [18]

> Трудозатраты на перевод любого проекта под Delphi XE не
> такие уж большие, если все самописное

Берешься оценить ? Или тоже больше по диагнозам спец ?

← →
DVM © (2011-08-19 22:34) [20]

> Игорь Шевченко © (19.08.11 22:28) [19]

> Берешься оценить ?

Чтобы оценить время перевода любого модуля со старой версии Delphi на новую, мне достаточно на него поглядеть. Соответственно надо смотреть все модули. Да не так все страшно как кажется.

Недавно только переводил два огромных модуля на Delphi XE (один для Extended MAPI второй для Lotus Domino) уложился в пару дней. Первый удалось сделать действительно юникодным, второй пока остался не юникодным, но в XE работает корректно.

← →
Игорь Шевченко © (2011-08-19 22:43) [21]

> Недавно только переводил два огромных модуля

ну давай посчитаем.

Модулей (*.pas, *.dpr, *.dpk) ~20000, средний размер 3 кило, 250 строк. Считаем, что написано более или менее правильно, Pointer к Integer и наборот встречается в тысячной части модулей, размер Char за единицу считается в сотой части.

Модулей (*.dfm) ~7000 (надеюсь, ты в курсе, что их тоже надо править)

от тебя требуется:

1. количество человеко-дней для того, чтобы этот зоопарк компилировался.
2. количество человеко-дней для того, чтобы этот зоопарк функционировал также, как и до перевода.

← →
DVM © (2011-08-19 22:57) [22]

> Игорь Шевченко © (19.08.11 22:43) [21]

> Модулей (*.pas, *.dpr, *.dpk) ~20000, средний размер 3 кило,
> 250 строк.

От души у вас там модулей. 1 модуль = один тип (класс) что ли? Ну да ладно.

> Pointer к Integer и наборот встречается в тысячной части
> модулей,

ну для XE это не критично, критично в XE2

> Модулей (*.dfm) ~7000 (надеюсь, ты в курсе, что их тоже
> надо править)

Я, если честно не в курсе чего там еще можно править, кроме шрифта. Обычно проблем не возникало.

> от тебя требуется:
>
> 1. количество человеко-дней для того, чтобы этот зоопарк
> компилировался.
> 2. количество человеко-дней для того, чтобы этот зоопарк
> функционировал также, как и до перевода.

глобальным поиском и заменой это все это может получиться перевести за неделю, а то и меньше. Но юникодным оно может и не станет. Будет куча варнингов о приведении string к ansistring и наоборот (в основном при передаче данных из / в интерфейс), но их для начала можно подавить директивами компилятора.

← →
Игорь Шевченко © (2011-08-19 23:02) [23]

> Я, если честно не в курсе чего там еще можно править, кроме
> шрифта

тип полей датасета и тип его же параметров, например

> глобальным поиском и заменой это все это может получиться
> перевести за неделю, а то и меньше. Но юникодным оно может
> и не станет. Будет куча варнингов о приведении string к
> ansistring и наоборот (в основном при передаче данных из
> / в интерфейс), но их для начала можно подавить директивами
> компилятора

Я сильно извиняюсь, а что на что надо глобально менять ?

← →
DVM © (2011-08-19 23:04) [24]

> Игорь Шевченко © (19.08.11 22:43) [21]

> Модулей (*.pas, *.dpr, *.dpk) ~20000, средний размер 3 кило,
> 250 строк

Кстати, серьезный проект (не уровня hello world, как ты выразился выше) вовсе не обязательно должен иметь безумное число модулей. Проектов с 20000 модулями один на миллион.

← →
Dennis I. Komarov © (2011-08-19 23:05) [25]

Я все понимаю, но так ли оно надо?

← →
Игорь Шевченко © (2011-08-19 23:10) [26]

DVM © (19.08.11 23:04) [24]

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

← →
DVM © (2011-08-19 23:11) [27]

> Игорь Шевченко © (19.08.11 23:02) [23]

> тип полей датасета и тип его же параметров, например

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

> Я сильно извиняюсь, а что на что надо глобально менять ?

я использую такой подход:

Если модуль не мой, и не стоит задача заточить его под юникод, то глобальная замена:
string -> ansistring, char - > ansichar, pchar - > pansichar, поиск вызовов length и осмотр окрестного к ней кода, не умножается ли она где на байты.

← →
DVM © (2011-08-19 23:13) [28]

> Игорь Шевченко © (19.08.11 23:10) [26]

> Я к другому: к тому, кто за это будет платить ?

Кому это все надо, тот и будет. Если никому не надо, то и смысла в переводе нет.

← →
Игорь Шевченко © (2011-08-19 23:18) [29]

DVM © (19.08.11 23:11) [27]

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

Слив засчитан

← →
Dennis I. Komarov © (2011-08-19 23:29) [30]

> Если модуль не мой, и не стоит задача заточить его под юникод,
> то глобальная замена:

В том и вопрос, а на кой тогда переходить?

← →
Anatoly Podgoretsky © (2011-08-19 23:30) [31]

> Eraser (19.08.2011 19:36:16) [16]

А нафига, ради моды что ли?

← →
Anatoly Podgoretsky © (2011-08-19 23:30) [32]

> Eraser (19.08.2011 19:36:16) [16]

А нафига, ради моды что ли?

← →
Anatoly Podgoretsky © (2011-08-19 23:30) [33]

> Eraser (19.08.2011 19:36:16) [16]

А нафига, ради моды что ли?

← →
Anatoly Podgoretsky © (2011-08-19 23:34) [34]

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

Это так, но мало кто до 2009 писал AnsiString, а не string и также по другим строка. Мы только что пережили переход с 16 бит на 32, хотя и сейчас встречаются перлы, типа P + 4, вместо P + SizeOf(Integer).

← →
DVM © (2011-08-19 23:35) [35]

> Dennis I. Komarov © (19.08.11 23:29) [30]

> В том и вопрос, а на кой тогда переходить?

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

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

← →
Anatoly Podgoretsky © (2011-08-19 23:40) [36]

> DVM (19.08.2011 22:57:22) [22]

А это потому что, команда схитрила и сделала Integer равным 4 байтам, хотя
много лет капала на мозги противоположное

> The generic integer types are Integer and Cardinal; use these whenever
> possible, since they result in the best performance for the underlying CPU
> and operating system.

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

← →
Dennis I. Komarov © (2011-08-19 23:41) [37]

> DVM © (19.08.11 23:35) [35]

ИМХО, в большенсве случаев - дань моде. Реально совсем не надо, тем более, если до этого работало без юникода. Там где реально надо, писали и на D7 а-ля tnt... Вот там и переходить проще

Хотя это мое скромное...

← →
DVM © (2011-08-19 23:58) [38]

> Anatoly Podgoretsky © (19.08.11 23:34) [34]

> Это так, но мало кто до 2009 писал AnsiString, а не string
> и также по другим строка.

Ну string простительно еще. Никто ж не знал как оно будет.

Pointer к NativeUInt еще меньше кто приводил, хотя тип существует с 2006 года как минимум.

Но когда вместо THandle используют Cardinal повсеместно и т.д. - это все говнокод на мой взгляд.

> Dennis I. Komarov © (19.08.11 23:41) [37]

> ИМХО, в большенсве случаев - дань моде. Реально совсем не
> надо, тем более, если до этого работало без юникода.

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

← →
Eraser © (2011-08-20 00:57) [39]

> [17] Игорь Шевченко © (19.08.11 20:34)

Поддержка юникода появилась 3 года назад. Можно было за этот срок выделить время на его внедрение. К тому же не так много работы перевести проект на юникод. Больше разговоров о том, что "не вижу возможности" и мифические немыслемые трудозатраты на это. Из своего опыта могу сказать, что это типичнейшая отговорка, конкретно в этом юникодном случае. Что они там виндовс пишут что ли?

← →
Eraser © (2011-08-20 01:02) [40]

> [37] Dennis I. Komarov © (19.08.11 23:41)

Дань моде это, возможно, только для программ, расчитанных на работу внутри какого-то одного конкретного учреждения или же для узкоспециализированных утилит, опять же, для внутренних нужд. В остальном, обязательно найдутся юзеры, которым понадобиться полноценный юникод. Про коробочные продукты и речи нет, там понадобится 100%.

← →
Игорь Шевченко © (2011-08-20 01:09) [41]

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

У тебя есть опыт. Давай ты переведешь ? В рамках шага доброй воли и потому что не лентяй, то есть, безвозмездно.

← →
Германн © (2011-08-20 01:42) [42]

> Anatoly Podgoretsky © (19.08.11 23:34) [34]
>
>
> > Так что еще проблемы с переводом - это результат халатного
> > отношения к работе ранее.
>
> Это так, но мало кто до 2009 писал AnsiString, а не string

Подозреваю, что таких не просто мало, а очень мало.
Клинические случаи не будем рассматривать. А из остальных только типа меня. Которые при отсутствии нормального финансирования (про которое упоминал ИШ) поддерживали и поддерживают проект созданный в Д1. Мне без явного указания типа AnsiString ну никак нельзя было обойтись, ибо очень часто использовались паскалевские строки с учетом их структуры.
Но мне тогда это было "жизненно необходимо"! 16-битная программа не могла работать с железом на NT-платформе.

← →
Германн © (2011-08-20 02:15) [43]

> Eraser © (20.08.11 00:57) [39]
>
> > [17] Игорь Шевченко © (19.08.11 20:34)
>
> Поддержка юникода появилась 3 года назад. Можно было за
> этот срок выделить время на его внедрение.

Срок-то да. А деньги?
Кто захочет тратить деньги за какой-то там Юникод, если ПО и так работает?

← →
Eraser © (2011-08-20 02:42) [44]

> [42] Германн © (20.08.11 01:42)

> Игорь Шевченко ©

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

← →
Германн © (2011-08-20 03:14) [45]

> А кто выделяет деньги на то, что программеры вместо работы
> сидят в соц. сетях, блогах

Я не сижу ни в соц.сетях, ни в блогах, ни даже в ЖЖ (куда меня регулярно пытался перенаправить Kerk). Я даже в интернет выхожу только изредка.

← →
Германн © (2011-08-20 03:23) [46]

> Eraser © (20.08.11 02:42) [44]
>
> > [42] Германн © (20.08.11 01:42)
>
>
> > Игорь Шевченко ©
>
> А кто выделяет деньги на то, что программеры вместо работы
> сидят

У тебя какая-то ненормальная фирма.
Не знаю точно как у ИШ, но с меня требуют результат. И именно в те сроки, которые были оговорены. А кто, где и как сидит, это уже не важно.

← →
Eraser © (2011-08-20 03:54) [47]

> [45] Германн © (20.08.11 03:14)

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

> [46] Германн © (20.08.11 03:23)

> У тебя какая-то ненормальная фирма.

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

← →
Игорь Шевченко © (2011-08-20 11:25) [48]

> А кто выделяет деньги на то, что программеры вместо работы
> сидят в соц. сетях, блогах или на форумах? Вот тот пусть
> и перераспределит рабочее время

Слив засчитан

← →
Anatoly Podgoretsky © (2011-08-20 11:54) [49]

Хорошую штуку ХЕ не назовут, надо минимум два ХЕ

← →
Inovet © (2011-08-20 12:40) [50]

> [49] Anatoly Podgoretsky © (20.08.11 11:54)
> два ХЕ

Квадратный ХЕ.

← →
Anatoly Podgoretsky © (2011-08-20 12:43) [51]

Ну да в квадрате XE^2

← →
Anatoly Podgoretsky © (2011-08-20 12:44) [52]

> Inovet (20.08.2011 12:40:50) [50]

И решить уравнение a+a=a*a

← →
Inovet © (2011-08-20 12:49) [53]

> [52] Anatoly Podgoretsky © (20.08.11 12:44)
> a+a=a*a

0, 2

← →
Anatoly Podgoretsky © (2011-08-20 12:56) [54]

> Inovet (20.08.2011 12:49:53) [53]

Ответ должен быть один и по теме, еще раз

XE+XE=XE*XE

Чему равно XE

← →
Inovet © (2011-08-20 12:59) [55]

Удалено модератором
Примечание: Offtopic

← →
Inovet © (2011-08-20 13:13) [56]

Удалено модератором
Примечание: Offtopic

← →
Компромисс (2011-08-20 13:33) [57]

Рефакторинг сам по себе не является благом. Если после рефакторинга появляются улучшения (уменьшение времени внесения изменений, повышения быстродействия, масштабируемости и т.д.), только тогда можно говорить благе.
В данном конкретном случае никакого блага не появляется, даже наоборот. Тратится время (которого нет) и появляется возможность для новых багов.
Вот если бы заказчик запросил поддержку юникода, то одним из вариантов решения был бы переход на другую версию Delphi. Причем, вполне могло оказаться, что был бы принят другой вариант решения ибо добавить поддержку а la tnt могло быть на N дней быстрее и без внесения новых багов.

Расскажу о своем опыте. Были проекты на D3, D4, D6. Выясняется, что в одном из приложений D3 есть утечка памяти, которая через пару недель работы приводит к зависанию сервера приложений. Принимается решение о переводе на D6 (хотя последняя версия уже D7), потому что 1) в D6 данный баг уже исправлен 2) есть специалисты с опытом работы именно на D6. То есть не придется искать/учить работника с D7. При этом все остальные приложения остаются на D3/D4.
"Работает - не трожь" никто не отменял.
А то проведете рефакторинг ("модернизацию"), а тебе за это лишение премии, за внесение новых багов. И никого не будет волновать, чего ты там еще добавил, потому что это что-то всё равно никому не нужно и никем не используется.

← →
oxffff © (2011-08-20 14:01) [58]

Все дело в том, что хороших специалистов единицы.

← →
Компромисс (2011-08-20 14:08) [59]

Все дело в том, что хороших специалистов единицы.

Причем некоторые из них еще и тратят свое бесценное время на никому пока не нужные переходы.

← →
Anatoly Podgoretsky © (2011-08-20 15:19) [60]

> Компромисс (20.08.2011 13:33:57) [57]

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

Д5, Д6, Д7 братья близнецы, по сути SP1 и SP2
Просто кушать хотелось.

← →
Anatoly Podgoretsky © (2011-08-20 15:22) [61]

> Компромисс (20.08.2011 14:08:59) [59]

Есть правило - продолжать поддерживать проект в той же версии и только если
обосновано тогда и переносить. Но с Д5 на Д7 как правило только
перекомпиляция, если конечно нет посторонних компонент

← →
Компромисс (2011-08-20 15:49) [62]

Есть правило - продолжать поддерживать проект в той же версии и только если
обосновано тогда и переносить.

Как раз это правило и обсуждалось в этой ветке.

← →
Eraser © (2011-08-20 17:07) [63]

> [57] Компромисс (20.08.11 13:33)

Вы описали классический подход к разработке софта. В целом я его противник, т.е. противник правила "работает - не трожь". На каком-то этапе действительно посчитают, что TNT проще, чем переход на новую версию. Сейчас вот выйдет XE2 с поддержкой 64 разрядности, потом через пару лет заказчик потребует сделать 64x версию программы. В итоге получим, что от TNT все равно придется избавляться и переходить таки на новую версию делфи, при этом переписывать придется гораздо больше. Да бог бы с ним с юникодом и 64x. Вот без дженериков рельно неудобно работать. Мое мнение, что нужно адаптивровать проект (если конечно проект расчитан на развитие, что далеко не обязательно должно быть так) к каждой новой версии компилятора.

← →
DVM © (2011-08-20 17:15) [64]

> Eraser © (20.08.11 02:42) [44]

+100

Кстати, бонусом от перехода на юникод будет еще повышение производительности программы, особенно интенсивно использующих WinAPI.

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

Переходить никого и никуда не агитирую. Просто категоричность некоторых умиляет.

← →
Игорь Шевченко © (2011-08-20 17:16) [65]

Anatoly Podgoretsky © (20.08.11 15:22) [61]

> Но с Д5 на Д7 как правило только
> перекомпиляция, если конечно нет посторонних компонент

а Variants когда выделился ? По-моему, в D6
И русский текст в dfm стал юникодным

← →
Игорь Шевченко © (2011-08-20 17:18) [66]

> Сейчас вот выйдет XE2 с поддержкой 64 разрядности, потом
> через пару лет заказчик потребует сделать 64x версию программы

Мечты.

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

Монгольский космонавт

← →
DVM © (2011-08-20 17:21) [67]

> Игорь Шевченко © (20.08.11 17:18) [66]

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

Это вы разработчику платных компонент расскажите

← →
Игорь Шевченко © (2011-08-20 17:58) [68]

DVM © (20.08.11 17:21) [67]

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

Всегда ваш,
К.О.

← →
Eraser © (2011-08-20 17:59) [69]

Это как с виндой. После выхода новой версии консерваторы года 2-3 орут, что пользоваться этой системой нельзя, корпорация зла опять все изуродовала и сидят на ОС 10 летней давности. Потом, как раз, к выходу уже следующего обновления, консерваторы наконец переходят на старую новую винду и начинают плодить ветки "а что такое UAC?", "а куда подевались мои файлы?" и т.п. От версии к версии такой цирк повторяется. По-моему проще сразу смириться с неизбежным и пробовать новые версии. Я не агитирую за то, что нужно кидаться на каждую новую бета-версию или RC, но за прогрессом основных инструментов работы нужно следить.

← →
Игорь Шевченко © (2011-08-20 18:01) [70]

Eraser © (20.08.11 17:59) [69]

> -моему проще сразу смириться с неизбежным и пробовать новые
> версии

http://russian.joelonsoftware.com/Articles/FireAndMotion.html

← →
Eraser © (2011-08-20 18:05) [71]

> [70] Игорь Шевченко © (20.08.11 18:01)

Читал, хорошая статья. только она немного по другой теме. новые версии инструментов и новые технологии это все таки разные вещи. если продукт уже около 10 лет разрабатывается на Делфи и дальше планируется разрабатываться на Делфи, то выгоднее всегда придерживаться последней версии IDE, т.к. все равно и переход на юникод неизбежен и внедрение x64. И чем раньше это делать, тем проще будет в будущем.

← →
Anatoly Podgoretsky © (2011-08-20 18:08) [72]

> Игорь Шевченко (20.08.2011 17:16:05) [65]

Не помню, но вроде бы в Д5, но если и так, то это такая мелочь, о которой
скажет компилятор

← →
asail © (2011-08-20 23:21) [73]

> Eraser © (20.08.11 17:07) [63]

> потом через пару лет заказчик потребует сделать 64x версию
> программы.

Вот заказчик пусть и оплачивает переход. Не только разработку, но и тестирование ессно тоже...

← →
DVM © (2011-08-20 23:26) [74]

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

Хочет заказчик или нет, хотим мы или нет, но век 32 бит программ и ОС подходит к концу. Лучше быть готовым к этому заранее. 32 бит программы еще поддерживаются в 64 бит системах, но вот 16 бит уже нет, а ведь не так давно казалось, что они живее всех живых. Никто не может гарантировать, что в следующей версии ОС не исчезнет поддержка 32 бит программ или она будет сильно ограниченной.

← →
Inovet © (2011-08-20 23:30) [75]

> [74] DVM © (20.08.11 23:26)
> что в следующей версии ОС не исчезнет поддержка 32 бит программ

16 бит аппратно не поддерживается, так что не ОС, а процессор с новым расширением. Но 16 бит 20 лет тащили в 32 процессорах.

← →
asail © (2011-08-20 23:42) [76]

> DVM © (20.08.11 23:26) [74]

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

← →
Игорь Шевченко © (2011-08-20 23:51) [77]

> 16 бит аппратно не поддерживается

Это где ?

← →
DVM © (2011-08-21 00:03) [78]

> Inovet © (20.08.11 23:30) [75]

> 16 бит аппратно не поддерживается

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

> Но 16 бит 20 лет тащили в 32 процессорах.

64 бит тоже не вчера появились.

> asail © (20.08.11 23:42) [76]

> Например, у нас очень большой проект

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

> 90% используют БДЕ для доступа к БД, а также сторонние компоненты,
> причем, некоторые из них уже не поддерживаются разработчиками,
> хоть и были платными.

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

> не переписывая почти все заного, я чета не очень себе представляю.
> ..

Я уже говорил, не так страшен черт. Не надо сразу все пытаться переписать. Во-первых, львиная доля (процентов 80 вменяемого кода) не нуждается ни в каких доработках. Emabarcadero все же пыталась максимально смягчить переход. Во-вторых, раз у вас куча dll - переводите их постепенно, это вполне возможно, на то они и dll.

← →
Inovet © (2011-08-21 00:06) [79]

> [77] Игорь Шевченко © (20.08.11 23:51)
> Это где ?

В режиме х64. Разве нет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inovet © (21.08.11 00:06) [79]

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

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

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

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

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

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

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

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

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

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

Eraser © (21.08.11 00:08) [80]

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

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

DVM © (21.08.11 00:19) [83]

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

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

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

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

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

Вот на что надо пыл направлять:
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-х разрядном окружении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Дмитрий С (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? Найти похожие ветки