Dlephi8

← →
Maza_Faka (2004-03-24 10:38) [0]

Как в D8 скомпилировать обыкновенное Delphi пирложение. Компилю новый VCL проект (пустое окно) и получаю exe файл размером 1.3 Mb. Затем добавляю на форму кнопку, компилю заново и получаю exe файл размером 8 Kb. Ни тот, ни другой на компах без D8 не запускаются. Так как же скомпилировать приложение, которое пойдет и под XP, и под W98 не требуя библиотек? Если никак, то Delphi умерла :(

← →
Тимохов © (2004-03-24 11:01) [1]

> то Delphi умерла :(

вместе с нетом

← →
Smithson © (2004-03-24 11:59) [2]

Delphi 8 ориентироана на .NET. Сам не пользовался, но могу предположить, что должна быть галка (приложение for .NET). Найди и сними ее.

← →
Delirium © (2004-03-24 12:03) [3]

"получаю exe файл размером 8 Kb" - это .Net сборка, и работать будет только там, где присутствуют Microsoft .NET Framework и необходимые сборки из D8.

← →
Agent13 © (2004-03-24 12:04) [4]

> могу предположить, что должна быть галка (приложение for
> .NET). Найди и сними ее.

Такой галки в природе нету! Д8 - она только для .нет, (к сожалению)

← →
Maza_Faka (2004-03-24 12:29) [5]

Так что, ничего похожего на D4-D7 больше никогда не будет? Будет только навязанная Microsoft .NET и аналоги MFC?

← →
Agent13 © (2004-03-24 12:34) [6]

> Так что, ничего похожего на D4-D7 больше никогда не будет?
> Будет только навязанная Microsoft .NET и аналоги MFC?

По инету ходят слухи, что может будет что-то вроде Delphi 8 for Win32, но на правду это непохоже. Во всяком случае, я не верю.

← →
TUser © (2004-03-24 12:37) [7]

Как ни печально но факт - рановато Борланд перестроился полностью на нет. Еще года 2-3 win32-приложения будут крайне распространенными, надо бы под эту платформу тоже развивать RAD"ы.

← →
Serge © (2004-03-24 12:38) [8]

Поищи по форуму, на днях был такой-же вопрос, там посоветовали скачать какую-то фигню для инсталяции в остальных версиях Виндовс - для совместимости с .NET - если не ошибаюсь и память не подводит.
Удачи

← →
Agent13 © (2004-03-24 12:41) [9]

> Еще года 2-3 win32-приложения будут крайне распространенными,

Даже больше. Лонгхорн только где-то через два года появится, так и то далеко не все сразу на него пересядут, а под Вин32 системами .нет программы, имхо, не имеют никаких преимуществ.

← →
Тимохов © (2004-03-24 12:43) [10]

я сам пока до д8 не добрался.
вопрос такой: что правда нельзя будет писать одновременно для нет и не для нет. Т.е. есть в проге достаточно низкоуровневые штуки (например, непосредственная работа с памятью и т.д.), но в тоже время есть и высокоуровневые (что-то типа объектов com). Так что нельяз будет это комбинировать? Нужно будет пользоваться только объектами net"a?

← →
Maza_Faka (2004-03-24 12:59) [11]

А нафига вообще этот .нет нужен: и без него хорошо жилось. В D7 надо было только IDE как у D8 сделать - и получилась бы среда разработки на все века.

← →
Тимохов © (2004-03-24 13:11) [12]

> А нафига вообще этот .нет нужен: и без

borland большой друго MS
знаю со слов человека работавшего консультантом borland в россии.
Борланд поддерживает МС в его начинаниях
И потому похоже двигает туда, куда хочет МС

← →
Anatoly Podgoretsky © (2004-03-24 13:15) [13]

Тимохов © (24.03.04 12:43) [10]
Неправда, для этого в поставке два компилятора Д7.1 и Д8, низкоуровневый доступ по определению не должен быть, это построено по объектовой технологии ОС (пока в виде надстройки) и работать надо с объектами ОС от них и наследоваться.
Какая я то поддержка необслуживаемого кода имеется, но лучше сразу отказаться от этого в том числе и от костылей от Борланда. Потом легче будет жить. А Борланд любит всовывать свои костыли во все технологии, например в АДО

← →
Serge © (2004-03-24 13:17) [14]

http://delphi84.valuehost.ru/cgi-bin/forum.pl?id=1079839256&n=0 - похоже надежд мало.

← →
Тимохов © (2004-03-24 13:18) [15]

> Anatoly Podgoretsky © (24.03.04 13:15) [13]

Скажите, Анатолий, что никакой возможности нет писать низкоуровневые штучки? Как же тогда вообще программировать? Что же весь office будет написан исключительно на net без всяких тонких (и соответственно быстрых) обработок памят?

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

А например, ms sql тоже будет переписан на net. Такого же тоже не может быть.

И вообще - почитать бы про это что вы рекоммендовали?

← →
Agent13 © (2004-03-24 13:19) [16]

> в том числе и от костылей от Борланда.

Вот про костыли вы это очень хорошо подметили. Потому что все борландовские наработки для .нет выглядят жалко. А VCL.NET вообще как "не пришей кобыле хвост".

← →
Игорь Шевченко © (2004-03-24 13:28) [17]

Agent13 © (24.03.04 13:19)

Тебя заставляют пользоваться ?
Странный ты...

← →
Vuk © (2004-03-24 13:28) [18]

to Agent13 © (24.03.04 12:34) [6]:
>По инету ходят слухи, что может будет что-то вроде Delphi 8 for
>Win32, но на правду это непохоже.
Уже не слухи ходят, а информация, подтвержденная Borland. Только будет это, скорее всего, в следующей версии. Я в "Потрепаться", помнится, текст заявления Borland приводил.

to Тимохов © (24.03.04 13:18) [15]:
>что никакой возможности нет писать низкоуровневые штучки?
Что есть "низкоуровневые штучки"? И почему без них нельзя?

>А например, ms sql тоже будет переписан на net.
А смысл? Win32 никуда не денется.

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

← →
Тимохов © (2004-03-24 13:54) [19]

> Почему это Вам так кажется?

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

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

Например, у нас есть подобие RS, только свое. Работа только в памяти, есть некий аналог sql. Работает быстро. И все из-за того, что есть возможность помудрить, причем строго в рамках документации дельфи, т.е. ничего недокумментированного.

Если этого не будет, то что же делать... :((((

А асм вставки... :(((((((

← →
Agent13 © (2004-03-24 14:01) [20]

> Игорь Шевченко © (24.03.04 13:28) [17]

> Тебя заставляют пользоваться ?
> Странный ты...

А кто сказал, что я пользуюсь? Я всего лишь высказал своё мнение о Д8, которое в общем-то и объясняет, почему я им не пользуюсь. Что же тут странного?

← →
Serginio666 (2004-03-24 14:04) [21]

Ну ничего очень скоро будешь пользоваться. А борланду нужно сильно поработать, что бы народ на C# не перешел.

← →
Игорь Шевченко © (2004-03-24 14:06) [22]

Agent13 © (24.03.04 14:01)

И я высказал свое мнение.

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

← →
Vuk © (2004-03-24 14:07) [23]

to Тимохов © (24.03.04 13:54) [19]:
>просто скопировать область памяти
Что есть в вашем понимании "область памяти"? Массив байтов?

>обмануть в своих целях дельфовый подсчет ссылок
Такой штуки как "дельфовый подсчет ссылок" в .net нет совсем. Зато там есть сборщик мусора и явный подсчет ссылок не нужен.

>Работа только в памяти, есть некий аналог sql.
Зависит от реализации.

← →
Agent13 © (2004-03-24 14:12) [24]

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

А вы щупали Д8 собственными руками? Я щупал и с моей ламерской точки зрения при наличии Framework Component Library от M$, VCL становится ну просто лишним.

← →
Тимохов © (2004-03-24 14:13) [25]

> Что есть в вашем понимании "область памяти"? Массив байтов?

например

move область памяти, содержащей строки в другое место
вызов для нее fillchar(0,....)

В этом случае в рамках Д6 все корректно, никаких утечек памяти, никаких av.

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

← →
Игорь Шевченко © (2004-03-24 14:16) [26]

Agent13 © (24.03.04 14:12)

> при наличии Framework Component Library от M$, VCL становится
> ну просто лишним.

Особенно при портировании старых проектов.

← →
Agent13 © (2004-03-24 14:21) [27]

> Особенно при портировании старых проектов.

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

← →
Vuk © (2004-03-24 14:28) [28]

to Тимохов:
>move область памяти, содержащей строки в другое место
Массивы замечательно умеют копировать свои данные. Опять же, потоки в памяти доступны...

Тимохов © (24.03.04 13:54) [19]
А асм вставки... :(((((((

Вот с этой ключевой фрази и начнем, какой к черту АСМ если система по определению платформенно не зависимая, и не только по ОС, но и по типу процессора, включая такие понятия как указатели или вообще доступ до памяти как класс.

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

Поддержка Win32 тоже останется в Windows.NET но уже на уровне эмуляции, как сейчас дело обстоит с ДОС и Win16.
Насчет MS SQL дело обстоит много интересней, сама файлавая система уже будет построена на основе MS SQL, а на самый нижний уровень как и сейчас нет доступа, только на уровне драйверов, то по всей видимости буде закрыт и этот путь.
Одна из задач системы это повышение ее надежности, за счет изолирования на пользовательском и системном уровне. Задача эта будет выполнена. Тебя не смущает, что в AS400, нет никакого уровня на низкий уровень в ОС, все только через объекты, вроде даже понятия адрес, файл отсутствуют, что не мешает этой системе быть весьма мощной и производительной.

А вот что Микрософт перепишет чисто под .NET а что оставит в режиме совместимости мы можем только гадать, но все равно это далекое будущее, или конец десятилетия или в следующем.

to Anatoly Podgoretsky © (24.03.04 14:34) [29]:
>Поддержка Win32 тоже останется в Windows.NET
Анатолий, какой такой Windows.net?

Agent13 © (24.03.04 14:21) [27]
В новых продуктах не стоит использовать VCL.NET об этом и Борланд говорит, сделано это для перевода старых продуктов.
Если следовать этому правилу, то можно ожидать мешьне проблем в будущем. Но придется потратить некоторые усиля над собой, для перелома психологии, но оно того стоит.

Vuk © (24.03.04 14:36) [30]
Это мое условное наименование, вроде это то что сейчас временно называет Лонгхорн, ОС построеная на основе технологии .net
Насколько я знаю Window 2003 Server .NET тоже, но могу ошибиться, специально не иследовал, а маркетинг производителей странная штука, моугт написать что угодно, выдать ОС c FremeWork за желаемое. Тоже может касаться и Лонгхорн.
Но из различных источников мне видится следующее

Windows 2000 Server - Windows XP
Windows 2003 Server Net - Longhorn

могу ошибаться

Значит так. Никакой эмуляции Win32 ни в Win2003 Server ни в Longhorn нет и не будет. Microsoft этого никогда не говорил. Наоборот, говорилось, что с Win32 ничего не произойдет.

> [33] Vuk © (24.03.04 14:47)

А вот я слышал обратное утверждение, от представителей MS.
Правда, в их технической компетенции я бы несколько посомневался, возможно - это заученная фраза. Но она была, точно!

Ну не знаю. На BDD на прямо заданный вопрос, что будет с Win32, ответил, что все как было так и останется. Единственное, что многие API, типа WinFX будут доступны только в .net.

← →
Algol (2004-03-24 16:07) [36]

По опыту программирования на C# могу сказать следующее:
1)Все функции Win32 API вызываются без проблем. Никакой интерпретации там нет. Старые Длл-ки как работали так и работают.
2)Прямой доступ к памяти возможен, правда он более муторный, поскольку осуществляется посредством специальных объектов.

← →
Serginio666 (2004-03-24 16:15) [37]

Vuk © (24.03.04 14:47) [33]
Будут только уже как надстройка над Net API. Правда и в бетном релизе используется Win 32.
Иначе как старые приложения работать будут. Таже проблема что и с Win 16.

to Serginio666:
>Будут только уже как надстройка над Net API.
Имелось в виду - не будут доступны напрямую.

KSergey © (24.03.04 15:41)

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

← →
Serginio666 (2004-03-24 18:35) [40]

>> Игорь Шевченко © (24.03.04 17:37) [39]
А куда им деваться.
Авалон на DirectX. Файловая система под Юконом. Причем все премущество манагед кода можно получить только используя системный библиотеки работающие на прямую, а не как сейчас являясь оболочкой вокруг Win32 API. Раз уж задумали такое дело ...
Этим как раз и можно объяснить не скорый выход Longhorn
Кроме того выход Net FrameWork 2 тоже задерживается хотя Whidbey и 1.2 и быстрее и многофункциональнее чем 1.1 и глюков не замечал.

Dlephi8 Найти похожие ветки