Компонент для чтения CF-формата. Описание CF-формата.
26.01.2011 12:04 21 [+] [−] Перейти к публикации
Что-то сомневаюсь я, что там так много зарезервированных байт. По моему опыту реверсинга (не связанному с 1С) часто они оказываются совсем не зарезервированными, а очень даже важными - что обычно проявляется при попытке записи данных.
Но всё равно плюс. Хоть это и ******** .NET.
| Цитата |
|---|
| Yashazz пишет:
На всякий случай: если что, можно я это возьму за основу работы со справочными данными (буду их тягать из cf)? |
Конечно, берите за основу. Библиотека бесплатная. Возможно, на ее основе в дальнейшем появяться какие-то платные продукты. Но именно этот компонент, планируем, останется бесплатным.
(4) То, что вы не поняли назначение "зарезервированных" байт - это не беда. Беда в том, что вы вводите всех в заблуждение, что первые четыре байта формата CF - это FF FF FF 7F. Это отнюдь не сигнатура, и не признак формата CF (для примера см. приложенный файл).
Формат CF давным давно открыт, и исходники для работы с ним лежат в открытом доступе (см. или ). Если уж решили описать формат, то хотя бы убедитесь сначала, что вы правильно поняли назначение всех полей!
| Цитата |
|---|
|
Если уж решили описать формат, то хотя бы убедитесь сначала, что вы правильно поняли назначение всех полей! |
Мы не обладаем экстрасенсорными способностями, исследуя закрытый формат FAR'ом. Мы собираемся убеждаться, что поняли назначение всех полей исходя из практики использования. В том числе из практики использования других пользователей. Компонент только выложен, значит практики применения не было. У вас есть другой вариант убедиться, что все правильно?
Ответили: (8)
(7) Конечно! Посмотреть на уже проделанную работу другими. Выше я привел ссылки на публикации с исходниками. Если бы вы были первопроходцами - другой разговор! Но не поинтересоваться перед публикацией, а что уже сделано по этой теме - имхо, не верно. Я уж не требую в публикации приводить ссылки на аналоги, хотя на инфостарте это считается хорошим тоном.
| Цитата |
|---|
| awa пишет:
Беда в том, что вы вводите всех в заблуждение, что первые четыре байта формата CF - это FF FF FF 7F. Это отнюдь не сигнатура, и не признак формата CF (для примера см. приложенный файл). |
Давайте, все-таки оставим формулировку сигнатура, так как эта же последовательность байт FF FF FF 7F используется еще в нескольких местах в описанном CF-формате, и все просмотренные мной cf- и epf-файлы начинаются с этой последовательности.
Что касается вашего примера - то я склоняюсь к тому, что это пример того, что 1С жестко не проверяет эти 4 байта. Дело в том, что если вы измените их на 00 00 00 00 или опять же на FF FF FF F7, то 1С откроет эту обреботку также, как и исходный пример. Исправьте эти байты на FF FF FF F7, чтобы было по описанному формату
.
Ответили: (10)
| Цитата |
|---|
| Конечно! Посмотреть на уже проделанную работу другими. Выше я привел ссылки на публикации с исходниками. Если бы вы были первопроходцами - другой разговор! Но не поинтересоваться перед публикацией, а что уже сделано по этой теме - имхо, не верно. Я уж не требую в публикации приводить ссылки на аналоги, хотя на инфостарте это считается хорошим тоном. |
Если бы речь шла о формате Flesh, я бы так и сделал. Этот формат достаточно навороченный, чтобы самостоятельно понять его. Что касается формата CF - ничего в нем "военного" нет. А написание компонента на C# (после того как CF-формат достаточно хорошо описан) занимает 4 часа + 4 часа на отладку.
Форматом CF я интересовался - он нигде не описан. Я нашел описание, вроде, для MD, Moxcel еще каких-то. Но CF - не нашел. Если есть такое описание, пожалуйста, дайте ссылку - я обязательно опубликую ссылку на аналогичное описание формата.
Что касается V8Update и v8cf - очень интересные ссылки. Хорошо, что вы их привели в обсуждении данной публикации. Сомневаюсь, что они мне чем-то помогут, так как С++ очень нечитабельный - его нужно смотреть под отладчиком. А запускать эти проекты под отладчиком смысла не вижу - результат уже получен.
| Цитата |
|---|
| Сомневаюсь, что они мне чем-то помогут, так как С++ очень нечитабельный - его нужно смотреть под отладчиком. А запускать эти проекты под отладчиком смысла не вижу - результат уже получен. |
Это просто жесть... я в ауте...
| Цитата |
|---|
| Это просто жесть... я в ауте... |
Сравните: нашел сходный код для v8Unpack и CfInspector:
В C#:
| Код |
|---|
byte[] idBytes = ReadBytes((int)(ph.FullSize - 20 - 4)); Encoding u16LE = Encoding.Unicode; ir.Id = u16LE.GetString(idBytes); |
Тоже самое в V8Unpack (C++)
| Код |
|---|
*ElemNameLen = (Elem.HeaderSize - CV8Elem::stElemHeaderBegin::Size()) / 2; for (UINT j = 0; j < *ElemNameLen * 2; j+=2) ElemName[j/2] = Elem.pHeader[CV8Elem::stElemHeaderBegin::Size() + j]; |
Мне больше нравится 1й вариант. Причем он работает корректнее - Unicode-кодировка не означает чтение каждого 2го байта - это все-таки нечто больше. При желании можно еще примеров найти.
Я ни в коем случе не хочу обижать автора v8unpack - он проделал огромную работу. Для своего времени проект просто выдающйися. И в v8unpack сейчас реализовано больше функционала, чем в нашем компоненте.
Есть еще один вывод: C# на 50-80 процентов сокращает код, а следовательно сокращает ошибки и время отладки. Для примера: 123 байта (С#) против 206 байт (С++).
(13)
Второй вариант будет работать быстрее на порядок, т.к. исключает лишние операции с памятью и использует меньше машинных инструкций. К тому же не использует виртуальную машину .NET, а это дополнительный тормоз.
И да, Unicode как раз всегда два байта, поэтому в корректности второго варианта у меня нет никаких сомнений.
Я согласен, что C# в данном примере читабельнее. Но это не значит что лучше. Ну и комментарии в коде рулят.
--
На то мы и программисты, чтобы писать эффективный код. А не просто читабельный.
------
Кстати, а что это за "магические числа"? Мне абсолютно непонятен их смысл. Нужно выносить такие вещи в константы и называть как-нибудь понятно. В приведенном куске кода на C++ такого нет.
| Цитата |
|---|
| ReadBytes((int)(ph.FullSize - 20 - 4)); |
| Цитата |
|---|
| Magister пишет:
Второй вариант будет работать быстрее на порядок, т.к. исключает лишние операции с памятью и использует меньше машинных инструкций. К тому же не использует виртуальную машину .NET, а это дополнительный тормоз. И да, Unicode как раз всегда два байта, поэтому в корректности второго варианта у меня нет никаких сомнений. Я согласен, что C# в данном примере читабельнее. Но это не значит что лучше. Ну и комментарии в коде рулят. -- На то мы и программисты, чтобы писать эффективный код. А не просто читабельный. |
C++ или C# - это вечный спор, похожий на спор, какая религия лучше. Есть некоторые задачи, когда C# вообще не справляется и кроме как на С++ эти задачи не решить. Например Native API в 1С 8.2
Но данная задача - не тот случай.
По быстродействию: .Net позволяет компилировать сборки в машинный код через утилиту ngen.exe, и в этом случае работа не будет вестись через виртуальную машину. На C# можно написать аналогичную С++ конструкцию обработки массива байт, но понятие Unicode здесь ключевое. И самое главное - в C# легче распараллеливать процессы. Пример в публикации показывает, как при получении результатов, одним методом .AsParallel() я задействую все 4 ядра своего процессора, убыстряя работу.
По эффективности: CfInspector проектировался так, чтобы им могли воспользоваться максимальное количество людей. .Net здесь выигрывает. Его проще связывать с проектами, чем С++. Разработчиков на .Net (С# + VB.Net) сейчас больше, чем на С++. Использовать его проще, чем v8Unpack. Даже новичок может воспользоваться параллельными вычислениями. И примеры использования достаточно наглядные.
Конечно, CfInspector - не эталон инженерной мысли, но он дает возможность выбирать.
| Код |
|---|
По быстродействию: .Net позволяет компилировать сборки в машинный код через утилиту ngen.exe, и в этом случае работа не будет вестись через виртуальную машину. |
| Цитата |
|---|
| По эффективности: CfInspector проектировался так, чтобы им могли воспользоваться максимальное количество людей. .Net здесь выигрывает |
Как мне использовать CfInspector, скажем, из Delphi 7? Или ещё лучше, на сервере под Linux, где я хочу хранить конфигурацию в git-репозитории?
| Цитата |
|---|
| Даже новичок может воспользоваться параллельными вычислениями |
И руки поотрывать бы тем, кто писал в 1С работу с .cf и тем более с хранилищем. Это ж надо было написать настолько тормозной код!
| Цитата |
|---|
| Magister пишет:
Согласен. Только вот не вижу я тут ничего такого, для чего параллельные вычисления должны дать прирост. Правда не вижу. И руки поотрывать бы тем, кто писал в 1С работу с .cf и тем более с хранилищем. Это ж надо было написать настолько тормозной код! |
Cf - это совокупность записей. В каждой записи есть тело, состоящее из массива байт. Этот массив байт нужно обработать - во многих случаях разархивировать. Если первым действием получить элементы и массивы байт, то параллельно можно обрабатывать эти массивы для каждого элемента. В публикации .AsParallel() дает прирост за счет этого.
Есть еще один момент, который не использует компонент - распараллелить обработку каждой страницы при получении элементов страницы. Как подойти - еще не знаю, да и, честно говоря, смысла не вижу - не такая это популярная тема.
Ответили: (43)
ИМХО, если компонент нельзя использовать напрямую в 1С 8, без другой, платной компоненты, то его практическая ценность как самостоятельного проекта на Инфостарте стремится к нулю. Основная засада с компонентами, насколько я понял, почти полное отсутствие комплектов компонент под 8.2, которые можно было бы использовать на сервере приложения на разных аппаратных платформах.
| Цитата |
|---|
| Cf - это совокупность записей. В каждой записи есть тело, состоящее из массива байт. Этот массив байт нужно обработать - во многих случаях разархивировать. Если первым действием получить элементы и массивы байт, то параллельно можно обрабатывать эти массивы для каждого элемента. В публикации .AsParallel() дает прирост за счет этого. |
Я не об этом говорю, это как раз понятно.
Я о том, что не в эту сторону оптимизировать надо. Это экстенсивный путь. Надо оптимизировать в сторону меньшего количества операций с памятью, кэширования всего чего только можно, чтения и распаковки данных по мере необходимости и только нужных, а не всех подряд и т.д. Тогда и распараллеливание не понадобится - и так всё будет быстро.
Добавлю свою ложку
| Цитата |
|---|
| В C#: Код
byte[] idBytes = ReadBytes((int)(ph.FullSize - 20 - 4)); Encoding u16LE = Encoding.Unicode; ir.Id = u16LE.GetString(idBytes); |
Вот в delphi код (взято из класса для работы с CF, EPF, ERF)
| Код |
|---|
CurHead:=V8Stream.ReadHead(); |
Если следовать вашей логике, то как говорится, круче delphi - только яйца.
Ведь код намного легче для восприятия человеком.
А вообще, таскать вместе с компонентой большую тележку с инструментами (.NET) как то....
Толи дело C++ или Delphi которые вы так не любите, зацепил DLL-ку и полетело.
Всегда улыбаюсь когда разработчик DLL весом в 100 кб, пишет
| Цитата |
|---|
| *** Для работы компоненты потребуется установленный Microsoft .NET Framework 3.5, который.... |
Вероятно тот кому очень нужен функционал библиотеки, и полезет за фреймверком, но в случае давно изъезженной темы "CF" вряд ли.
Тем более, что ничего нового по сути ваша компонента не дает.
Ответили: (21)
(20) наезды на .net непонятны - это технологии, все плюсы .net можно на msdn найти и их не мало, и net это не тележка с инструментами, все таки это платформа, и зачем люди пишут epf обработки, таская с собой целую тележку 1С 
Круче разве, что крутой разработчик. Но в целом, конечно соглашусь с вами и с Magister, а данная разработка для меня представляется пока как "а можно сделать и вот так", как же это применять на практике, не знаю.
ЗЫ А дот нет как мне представляется очень хорош в крупных проектах, когда разработчиков не один и надо как можно быстрее выдавать результат, как например быстрое развертывание каких-нибудь веб решений на аспнете
(21) наезды на .net сводятся к тому, что это дополнительный груз для программ, и к тому же не кроссплатформенный. к тому же не самый удобный с точки зрения программиста (см. выше пример на Delphi ). но зато очень раскрученный, в отличие от остальных.
а насчет epf - сравнение некорректное, т.к. 1С это специализированный инструмент, а .NET позиционируется как универсальный.
Ответили: (23)
(22) настоящей кроссплатформенностью никто похвастать не может, пока что дот нет в теории только может...раскрученный это да, но в этом есть микрософтские планы развития, существующее же решение .net представляются мне пока, что как решение в режиме совместимости со старыми приложениями - com. Насчет удобности это субъективно, кто к чему привык - вон грозные, старые дядьки привыкли к ассемблеру. Насчет дополнительного груза, как сказать...сравнение с 1С может и некорректное, но все условность...просто я хотел сказать, что все годится в каждом конкретном случае, у delphi тоже есть свои недостатки, порой старую прогу на delphi проще с нуля написать на том же delphi...
| Цитата |
|---|
| настоящей кроссплатформенностью никто похвастать не может |
Ну и про Pascal забывать не стоит, вот возьмите тот же Lazarus - из одних исходников получаем софт под Linux/Windows/MacOS.
Ну и Java таки кроссплатформенна, хотя тормоз тот ещё.
| Цитата |
|---|
| BorovikSV пишет:
Добавлю свою ложку |
Delphi - это отдельная история. Последние версия Delphi, насколько мне известно, полностью поддерживает .Net. Значит и разработчики Delphi в нем что-то нашли.
Поэтому согласен, конструкция
| Код |
|---|
byte[] idBytes = ReadBytes((int)(ph.FullSize - 20 - 4)); Encoding u16LE = Encoding.Unicode; ir.Id = u16LE.GetString(idBytes); |
на Delphi 8 будет выглядеть один в один.
Ответили: (33)
| Цитата |
|---|
| Magister пишет:
наезды на .net сводятся к тому, что это дополнительный груз для программ, и к тому же не кроссплатформенный. к тому же не самый удобный с точки зрения программиста (см. выше пример на Delphi ). но зато очень раскрученный, в отличие от остальных. |
.Net, думаю, скоро будет встроен в Windows и устанавливаться автоматически (не помню, может в Windows 7 и 2008 так уже и есть). C DirectX были такие же сложности - пакет установки объемный, нужно отслеживать версии. В Windows 7 идет встроенным DirectX 11, и многие проблемы снялись сами собой.
Мне связка .Net + C# очень нравятся - эта связка позволяет писать быстро программы повышенного качества. Сообщество .Net-просто огромное, и как следствие решения для большинства проблем уже найдены. MSSQL 2005/2008 не стесняются пользоваться .Net, хотя это продукты, изначально нацеленные на быстродействие.
Ответили: (29)
| Цитата |
|---|
| Magister пишет:
|
На голом С достаточно легко написать кроссплатформенное решение "Hello World!". Все приложения, которые сложнее, потребуют значительных затрат моего времени. Как получать/записывать данные? У MS есть ODBC, ADO - у Linux наверняка тоже что-то есть, но не ODBC/ADO. Значит нужно мне самому описывать разные подходы для разных ОС. Тоже самое интерфейс пользователя - у MS DirectX (для WPF-варианта), у Linux не DirectX - мне самому писать 2 интерфейса для 2х ОС?
Недавно на Mista.ru был интересный вопрос - какой аналог COM у Linux - оказалось его нет.
Мое мнение: кроссплатформенность хороша, когда пишется изолированное приложение. В современном мире такого не бывает. Нужно писать хорошо под одну платформу, используя ее сильные стороны. Если есть спрос, можно переписать его для другой платформы. Для .Net framework есть альтернатива под Linux - это проект Mono.
Добавлю -, если C такой кроссплатформенный, нафига микрософту interix, чего это они мучаются с портированием хороших сишных программ с никсов? Ответ наверное кроется в абсолютном различии самих платформ, ...ну блин тогда все языки кроссплатформенны, ...мы же говорим не про существование различных диалектов языков на различных платформах (delphi, этот freepascal c надстройкой лазарус), а про теоретический перенос приложения в идеале даже перекомпиляции не требующий - ну так этого ни у кого нет. Насчет net framework - одна из попыток облегчить жизнь разработчику, начиная с xp(ну по крайней мере с висты) идет в составе дистрибутива ОС, насчет того интегрирована в ОС, сомневаюсь - для меня интеграция это когда ОС уже жить без этого не сможет, а винда может обходится без нета. Но судя по проекту сингулярити, микрософт нацелен использовать идею нета основательно. Насчет Delphi - да 8 была ориентирована на net - по моему чуть ли не одной из первых (и я бы не сказал, что удачной), потом микрософт дал ей по лапам(от делфи еще разработчик насколько я помню в нет перешел), и вроде проект немного приостыл. Затем после многочисленных перекупок, покупок - появились delphi .prism, hydra и даже бесплатный free pascal engine. Технологии. Это же хорошо. Конечно и про С забывать не стоит. Но это как автомобили, - каждый выбирает для своих целей.
___________
ЗЫ опечатка не free pascal engine, а конечно же pascal script, вроде как его использует redline для исы и форефронта - но могу и ощибатся
ЗЫ сорри за непростительно печатание анг буков - русскими - тороплюсь....
Ответили: (29)
(26) Под словами "груз для программ" я имел ввиду не то, что нужно что-то устанавливать, а то, что фактически простейшая утилитка при запуске съедает явно слишком большой для неё объем памяти. Лично я вижу только одно оправданное применение для .net - написание бизнес-логики. И то только там, где скорость и потребляемая память не критичны. Остальное - от лукавого. И да, MS SQL Server не написан на .net, он лишь имеет привязки к нему.
(27) А вы писали кроссплатформенные приложения на C? Получать/записывать данные? Пожалуйста вам, используйте кроссплатформенную СУБД - PostgreSQL, MySQL, DB2. Они все имеют интерфейсы к C, которые не зависимы от платформы. Интерфейс пользователя? Пожалуйста, используйте QT/GTK+/wxWindows.
Аналог COM? Действительно, его нет. Но это не мешает писать сложные програмы, просто подход другой использовать нужно.
Не нужно искать аналоги технологий Microsoft в других ОС. Нет их, и не должно быть - это невыгодно самой Microsoft.
(28) Потому что эти программы достаточно низкоуровневые. Мы же ведем речь о прикладных программах, где вся эта низкоуровневость должна скрываться рантаймом языка программирования и комплектом кроссплатформенных библиотек.
А Lazarus - это не Delphi, а абсолютно другая платформа, частично совместимая с Delphi на уровне исходников. И программы, написанные в ней, достаточно легко переносятся под Windows/Linux/MacOS X.
Ответили: (30)
(29) Я знаю, что не Delphi, пришлось писать на лазаре как-то, не понравилось честно, идея хороша, но это больше для учебы и студенчества подходит. Я имел ввиду, что кроссплатформенность в идеале недостижима, к примеру видите какие вопросы задают- есть ли аналог com в linux? Есть ли велосипеды у марсиан, может и есть, но не велосипеды. Платформы настолько различные между собой, что кроме как придумывание оберток, над-оберток мне кажется ничего не придумать. Насчет бизнес-логики, да соглашусь. Насчет легко переносимости, это прямо пропорционально сложности проекта и, все возрастающих зависимостей от родной платформы. А еще знаете как - я просто не силен в С, а тут модный дотнет, с синтаксисом, после моего засиживания на delphi, очень приятным - потому мое мнение предвзято. А Elisy - уважаю, все равно молодец, может компонента и несет в себе скорее теоретический смысл, но кто знает - может это начало чего-то большего.
Ответили: (32)
| Цитата |
|---|
| Magister пишет:
А вы писали кроссплатформенные приложения на C? Получать/записывать данные? Пожалуйста вам, используйте кроссплатформенную СУБД - PostgreSQL, MySQL, DB2. Они все имеют интерфейсы к C, которые не зависимы от платформы. Интерфейс пользователя? Пожалуйста, используйте QT/GTK+/wxWindows. Аналог COM? Действительно, его нет. Но это не мешает писать сложные програмы, просто подход другой использовать нужно. Не нужно искать аналоги технологий Microsoft в других ОС. Нет их, и не должно быть - это невыгодно самой Microsoft. |
Сомневаюсь, что я буду писать когда-либо кроссплатформенные приложения на С для 1С:Предприятие. 1С - это ОС традиционно Windows, если СУБД - традиционно MSSQL. 90% потребностей такое допущение охватывает. Здесь кроссплатформенность не нужна. Зато допущение позволяет на .Net значительно быстрее, чем на C, создавать разработки с меньшим числом ошибок. Нужна оптимизация по быстродействию - задействуется многопоточность или можно переписать часть кода на С++.
Аналоги технологий Microsoft есть - для .Net framework - это проект Mono (для Silverlight - проект Moonlight). Поэтому выбор .Net framework близок к многоплатформенному.
Ответили: (32)
(30) Вобщем согласен.
(31) 1С как раз сейчас этот стереотип разрушает. И ИМХО скоро будет 1С - сервер под Linux, СУБД - DB2 (или даже Oracle). У кого денег поменьше - у тех PostgreSQL.
А Mono... теоретически да, аналог. Только вот присмотритесь внимательнее, что он поддерживает. По крайней мере WPF там нет и врядли появится. Как и многое другое.
| Цитата |
|---|
| Elisy пишет:(25)
Delphi - это отдельная история. Последние версия Delphi, насколько мне известно, полностью поддерживает .Net. Значит и разработчики Delphi в нем что-то нашли. |
Вам неправильно известно. Последняя версия DELPHI - RAD STUDIO XE. К NET не имеет почти никакого отношения.
Знающие подтвердят, что среда разработки очень "похорошела". Но попытки миграции в сторону NET (после выхода версии DELPHI 8 .NET) больше не происходили.
Ответили: (34)
(33) Подтверждаю, но я не стал придираться, смысл то мне был понятен....скорее всего был спутан Delphi .Prism, который предлагается той же кампанией, но это отдельный продукт, имеющий несколько другое происхождение - скажу лишь, что он тоже относится к объект паскальным языкам(язык oxygene).
| Цитата |
|---|
| BorovikSV пишет:
Вам неправильно известно. Последняя версия DELPHI - RAD STUDIO XE. К NET не имеет почти никакого отношения. Знающие подтвердят, что среда разработки очень "похорошела". Но попытки миграции в сторону NET (после выхода версии DELPHI 8 .NET) больше не происходили. |
Значит у меня устаревшие данные:
"Вообще говоря, во всех презентациях Delphi 8 называлась как версия Delphi 8 for .Net, и всячески говорилось, что это следующий шаг развития Delphi. Аудитория пыталась вопросами прояснить, как быть со старыми приложениями, написанными на предыдущих версиях Delphi. Но Сергей Орлик не сдавал позиции, отвечая уклончиво, говоря, что потребуется минимум изменений для переноса под .Net и т.п., пока не получил вопрос в лоб:
В: Имеется ли возможность разрабатывать на Delphi 8 приложения под Win32 для Windows 95?
О: С Delphi 8 поставляется в комплекте Delphi 7. (Дружный смех в зале)"
Если есть у вас ссылки на более свежее описание стратегий Delphi и CBuilder, пожалуйста, поделитесь. Мне эта тема тоже интересна.
Ответили: (36)
(35) Ну, конечно, это очень устаревшие сведения - с тех пор (2004 год статьи с мисты) утекло много воды. Начнем с истории - (ИЗ вики)Во-первых Delphi оказал огромное влияние на создание концепции языка C# для платформы .NET. Многие его элементы и концептуальные решения вошли в состав С#. Одной из причин называют переход Андерса Хейлсберга, одного из ведущих разработчиков Дельфи(Про что я уже упоминал), из компании Borland Ltd. в Microsoft Corp. Версия 8 способна генерировать байт-код исключительно для платформы .NET. Это первая среда, ориентированная на разработку мультиязычных приложений (лишь для платформы .NET); (По многочисленным отзывам имела ряд серьезных недостатков - почему и не была принята благосклонно среди net разработчиков, я же 8-ку только один раз видел)
Последующие версии обозначались годами выхода, а не порядковыми номерами, как это было ранее. В настоящее время, в Delphi 2006, можно писать приложения для .NET, используя стандартную библиотеку классов .NET, VCL для .NET. Среда также позволяет создавать .NET-приложения на C# и Win32-приложения на C++. Delphi 2006 содержит функции для написания обычных приложений с использованием библиотек VCL и CLX.
Delphi 2006 поддерживает технологию MDA с помощью ECO (Enterprise Core Objects) версии 3.0.В марте 2006 года компания Borland приняла решение о прекращении дальнейшего совершенствования интегрированных сред разработки JBuilder, Delphi и C++ Builder по причине убыточности этого направления. Планировалась продажа IDE-сектора компании. Группа сторонников свободного программного обеспечения организовала сбор средств для покупки у Borland прав на среду разработки и компилятор.Однако в ноябре того же года было принято решение отказаться от продажи IDE бизнеса. Тем не менее, разработкой IDE продуктов теперь будет заниматься новая компания — CodeGear, которая будет финансово полностью подконтрольна Borland.В августе 2006 года Borland выпустил облегченные версию RAD Studio под именем Turbo: Turbo Delphi (для Win32 и .NET), Turbo C#, Turbo C++. В марте 2008 года было объявлено о прекращении развития этой линейки продуктов.В марте 2007 года CodeGear порадовала пользователей обновленной линейкой продуктов Delphi 2007 for Win32 и выходом совершенно нового продукта Delphi 2007 for PHP.(2007 - вообще стала любимой многими-здесь-то как раз дотнета уже и нет, а delphi 2007 for php - это попытка реализовать визуальное программирование на php, ход, конечно интересный)
Embarcadero RAD Studio в августе 2008 года компания Embarcadero, новый хозяин CodeGear, опубликовала пресс-релиз на Delphi for Win32 2009.[7] Версия принесла множество нововведений в язык, как то[8]:По умолчанию полная поддержка Юникода во всех частях языка, VCL и RTL; замена обращений ко всем функциям Windows API на юникодные аналоги (то есть MessageBox вызывает MessageBoxW, а не MessageBoxA).
Обобщённые типы, они же generics.
Анонимные методы.
Новая директива компилятора $POINTERMATH [ON|OFF].
Функция Exit теперь может принимать параметры в соответствии с типом функции.
Новинки XE (в основном связанные с облаками) в роликах
Ну и на ихнем сайте www.embarcadero.com, скажу сразу дотнета там нету. ДотНет у них есть в Delphi .Prism, язык Oxygene
Ответили: (39)
У Delphi Prism вообще история интересная (советую погуглить),прототипом был Object Pascal-ный язык Chrome - развивалась насколько я помню отдельно от Delphi кампанией RemObjects Software - появился язык (для CLR) Oxygene, затем после многочисленных изменений в кампаниях, покупок - стал Delphi Prism - полноценный паскальный для дотнета, совместимости с Delphi никакой. Установка возможна как на радстудию Delphi, так и на Visual Studio.
Ответили: (39)
Добавлю, что в России популярности последние продукты Delphi по всей видимости не получили. Либо все остались верны старым версиям (в основном 6,7 и 2007), либо перешли на дотнет.
Ответили: (39)
| Цитата |
|---|
| Elisy пишет:
Вижу, у Borland не все так гладко, нет стабильности и четкой стратегии |
А у кого она есть эта стабильность?
Microsoft своими финансовыми вливаниями только и продвигает NET.
Дай Borland (CodeGear, а ныне EmbarCadero) на DELPHI столько денежных средств, думаю в течении года от NET камня от камня не останется.
Если решение удачное, то в массы оно ой как хорошо проходит. А если за уши притягивают то со скрипом.
| Цитата |
|---|
| cool.vlad4 пишет:
Добавлю, что в России популярности последние продукты Delphi по всей видимости не получили. Либо все остались верны старым версиям (в основном 6,7 и 2007), либо перешли на дотнет. |
Ну я знаю многих кто на 2009 сидит. Сейчас постепенно на XE переходят. Конечно поголовно у всех "левые" стоят, но популярности этот факт не отнимает.
Кто Visual Studio купил вообще ни одного не знаю, так что вот...
А вообще что NET, что DELPHI, что 1С - это лишь инструмент. А важна на самом деле лишь выполняемая задача. Способов решения может быть много, кто как привык, и у кого как руки под тот или иной инструмент заточены.
Если на одну чашу весов положить NET + DELPHI, а на другую 1C, то в условиях российской действительности 1С перетянет в мгновение ока. Ведь на NET или DELPHI програмнные комплексы разрабатывают единицы (не считая нескольких DLL, EXE для внутренних нужд), а решений на основе 1С - куда не плюнь. Поэтому и объем рынка огромен.
Нельзя забывать еще о таком показателе как "стоимость владения". Перед затратами на разработку, сопровождение, доработку средствами NET и DELPHI - стоимость самой платформы 1С - просто пустяки. А многим важен именно этот показатель, а не тот факт что платформа стоит денег.
Если для платформы "1С" как для IDE выпустят API для изменения самой среды, а также реализуют многопоточность, то поверьте для NET и DELPHI (в России по крайней мере), останется еще меньше места.
Для 7.7 в частности появление технологий OpenConf и таких библиотек как 1C++, дало 7.7 второе дыхание и существенно затруднило переход на 1C 8.Х. (Затруднила с точки зрения ЗАО "1С").
А что произошло? Просто подключили несколько сторонних DLL к 1С 7.7, и среда преобразилась.
Так что возможно текущая версия 8.2 пройдя путь к 9.0, научится еще многим вкусностям о которых даже не подозреваем.
(17)
Таки нашел времени выложить свою наработку:
Пока распаковывает не всё - видимо, где-то ошибся при чтении данных, разбитых на несколько блоков, но по скорости получилось, как мне кажется, неплохо.
Написано на Lazarus.
Как будет время довести до ума - доведу и выложу публикацией.
21 [+] [−] Перейти к публикации
Вы совершенно не разобрались в формате CF.