gifts2017

Компонент для чтения CF-формата. Описание CF-формата.

Опубликовал Сергей Карташев (Elisy) в раздел Программирование - Теория программирования

Вышла первая версия бесплатного .Net-компонента Elisy.CfInspector для чтения CF-формата, совместимого с форматом 1С-конфигураций и внешних обработок. Для использования требуется .Net framework 4.0.

Вы можете ознакомиться с описанием CF-формата здесь.

Хотя использовать компонент можно из 1С при помощи компонента Elisy .Net Bridge, но максимальный эффект будет получен при использовании из .Net-проектов.

Для использования необходимо создать подходящий проект в Visual Studio. Добавить ссылку на сборку Elisy.CfInpector.dll. При необходимости вставить директиву:

using Elisy.CfInspector;

Пример обращения к компоненту:

var stream = new FileStream(@"D:\228\1Cv8.cf", FileMode.Open, FileAccess.Read, FileShare.Read);
Image image = ImageReader.ReadImageFrom(stream);

В результате вызова ReadImageFrom произойдет создание объекта типа Image. Image содержит несколько свойств, самым полезным из которых является Rows. Rows возвращает массив объектов ImageRow[]. Это и есть содержимое файла, записанного в формате CF. ImageRow определяет несколько свойств: Id – идентификатор данных, BodyRawData – тело в виде массива данных, Body – распознанное содержимое, которое может принимать типы: String, Image, byte[]. BodyType определяет тип данных:

  • CompressedUtf8MarkedString – сжатая строка;
  • CompressedImage – сжатый объект составного типа;
  • Utf8MarkedString – несжатая строка;
  • CompressedMoxcel – сжатый объект Moxcel;
  • Unknown – неизвестный тип.

Пример простого запроса к свойству Row – получить все данные с составным типом:

var request = from ir in image.Rows
    where ir.BodyType == ImageRowTypes.CompressedImage
    select ir;
var array = request.ToArray();

В .Net framework 4 есть достойная фича: Parallel LINQ. Используя параллельные вычисления, запрос можно выполнить значительно быстрее. Достаточно воспользоваться конструкцией AsParallel():

var request = from ir in image.Rows.AsParallel()
    where ir.BodyType == ImageRowTypes.CompressedImage
    select ir;
var array = request.ToArray();

Вот еще несколько примеров запросов:

Выбрать все макеты:

var request = from ir in image.Rows.AsParallel()
    where ir.BodyType == ImageRowTypes.CompressedMoxcel
    select new { a = ir.Id, b = Convert.ToString(ir.Body) };
var array = request.ToArray();

Выбрать все основные объекты:

var request = from ir in image.Rows.AsParallel()
    where !ir.Id.Contains('.')
    select new { a = ir.Id, b = Convert.ToString(ir.Body) };
var array = request.ToArray();

Найти корневой элемент:

var request = from ir in image.Rows.AsParallel()
    where ir.Id == "root"
    select ir.Body as string;
var root = request.FirstOrDefault();

Желаем успехов в экспериментах.

Отзывы принимаются здесь.

CfInspector.zip (4.21 kb)


Статья описывает CF-формат, совместимый с форматом 1С-конфигураций и внешних обработок. Планируется, что описание данного формата ляжет в основу .Net-компонента Elisy.CfInspector. Появление такого инструмента даст возможность запустить новые проекты:

  • CfXmlDoc - построение файлов помощи (SDK help) для 1С-разработчиков на основе XML-комментариев модулей 1С;
  • CfProject – распаковка и сборка конфигураций 1С для удобного хранения в системах управления версиями, например, Subversion (SVN);
  • CfSecurity – защита конфигураций через компилирование 1С-модулей в сборки .Net и запуск их из 1С через Elisy .Net Bridge.

Общее расположение блоков CF-файла представлено на рисунке:

Общее расположение блоков CF-файла

Файл состоит из заголовка образа (ImageHeader) и следующими за ним страницами (ImagePage1-ImagePageN). Заголовок образа состоит из 4х байт сигнатуры, которая равна 0xFF 0xFF 0xFF 0x7F, 4х байт размера страницы и 8 зарезервированных байт. После заголовка файла идут по порядку страницы с данными. Каждая предыдущая страница ссылается на последующую.

Каждая страница (ImagePage) состоит из заголовка страницы (ImagePageHeader), группы указателей на записи данных (ImageRowPointers) и области данных (ImageRows).

Заголовок страницы ImagePageHeader содержит в себе: зарезервированные 2 байта 0x0D 0x0A, 27 байт текстовой информации и еще зарезервированные 2 байта 0x0D 0x0A. Текстовая информация содержит 3 шестнадцатеричных числа: общий размер данных всех страниц (FullSize), размер текущей страницы (PageSize) и адрес следующей страницы в файле (NextPageAddress). FullSize проставляется только для первой страницы цепочки страниц. Для остальных страниц цепочки это значение 0. Для последней страницы цепочки NextPageAddress принимается равным 0xFF 0xFF 0xFF 0x7F.

Блок указателей на данные (ImageRowPointers) занимает размер, указанный в значении PageSize страницы. Каждый указатель состоит из 4х байт адреса заголовка данных (HeaderAddress) и 4х байт адреса тела данных (BodyAddress). В конце каждого указателя помещается сигнатура 0xFF 0xFF 0xFF 0x7F. Адреса указывают на расположения внутри текущей страницы на область данных (ImageRows).

Заголовок данных (ImageRowHeader) начинается с блока заголовка страницы ImagePageHeader, который сообщает, сколько байт отведено под заголовок. Далее идут 20 зарезервированных байт, UTF-16 строка идентификатора данных (Id) и 4 зарезервированных байт.

Тело данных (ImageRowBody) начинается с блока заголовка страницы ImagePageHeader, который сообщает, сколько байт отведено под тело данных. Если тело данных начинается на 0xEF 0xBB 0xBF (сигнатура UTF8), то тело содержит UTF-8 строку. Иначе тело данных содержит упакованные данные. Если распакованные данные начинаются на 0xFF 0xFF 0xFF 0x7F, то содержимое – совокупность объектов данных, и они записаны в CF-формате. Иначе содержимое данных – это строка сериализации.

// //

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Elisy.CfInspector.dll v.1.1
.dll 21,00Kb
02.07.13
13
.dll 21,00Kb 13 Скачать
Elisy.CfInspector.dll v.1.0
.zip 4,21Kb
02.07.13
75
.zip 4,21Kb 75 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Валерий Агеев (awa) 26.01.11 14:18
Заголовок образа состоит из 4х байт сигнатуры, которая равна 0xFF 0xFF 0xFF 0x7F, 4х байт размера страницы и 8 зарезервированных байт.

Если распакованные данные начинаются на 0xFF 0xFF 0xFF 0x7F, то содержимое – совокупность объектов данных, и они записаны в CF-формате.

Далее идут 20 зарезервированных байт

Вы совершенно не разобрались в формате CF.
2. Яков Коган (Yashazz) 26.01.11 16:09
На всякий случай: если что, можно я это возьму за основу работы со справочными данными (буду их тягать из cf)?
3. Misha ⁠ (Magister) 26.01.11 20:14
Что-то сомневаюсь я, что там так много зарезервированных байт. По моему опыту реверсинга (не связанному с 1С) часто они оказываются совсем не зарезервированными, а очень даже важными - что обычно проявляется при попытке записи данных.
Но всё равно плюс. Хоть это и ******** .NET.
4. Сергей Карташев (Elisy) 27.01.11 06:11
awa пишет:
Вы совершенно не разобрались в формате CF

Вместо "зарезервировано" читайте - "назначение не известно". Постепенно их назначение будет проясняться.
5. Сергей Карташев (Elisy) 27.01.11 06:14
Yashazz пишет:
На всякий случай: если что, можно я это возьму за основу работы со справочными данными (буду их тягать из cf)?

Конечно, берите за основу. Библиотека бесплатная. Возможно, на ее основе в дальнейшем появяться какие-то платные продукты. Но именно этот компонент, планируем, останется бесплатным.
6. Валерий Агеев (awa) 27.01.11 09:26
(4) То, что вы не поняли назначение "зарезервированных" байт - это не беда. Беда в том, что вы вводите всех в заблуждение, что первые четыре байта формата CF - это FF FF FF 7F. Это отнюдь не сигнатура, и не признак формата CF (для примера см. приложенный файл).
Формат CF давным давно открыт, и исходники для работы с ним лежат в открытом доступе (см. v8Unpack или v8cf). Если уж решили описать формат, то хотя бы убедитесь сначала, что вы правильно поняли назначение всех полей!
Прикрепленные файлы:
Судоку.epf
7. Сергей Карташев (Elisy) 27.01.11 09:36

Если уж решили описать формат, то хотя бы убедитесь сначала, что вы правильно поняли назначение всех полей!

Мы не обладаем экстрасенсорными способностями, исследуя закрытый формат FAR'ом. Мы собираемся убеждаться, что поняли назначение всех полей исходя из практики использования. В том числе из практики использования других пользователей. Компонент только выложен, значит практики применения не было. У вас есть другой вариант убедиться, что все правильно?
8. Валерий Агеев (awa) 27.01.11 10:03
(7) Конечно! Посмотреть на уже проделанную работу другими. Выше я привел ссылки на публикации с исходниками. Если бы вы были первопроходцами - другой разговор! Но не поинтересоваться перед публикацией, а что уже сделано по этой теме - имхо, не верно. Я уж не требую в публикации приводить ссылки на аналоги, хотя на инфостарте это считается хорошим тоном.
9. Сергей Карташев (Elisy) 27.01.11 10:06
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. Валерий Агеев (awa) 27.01.11 10:37
(9) Понятно, Вы просто уперлись в своем неведении, и не желаете действительно разобраться с форматом. Продолжение разговора считаю бессмысленным.
11. Сергей Карташев (Elisy) 27.01.11 10:48
Конечно! Посмотреть на уже проделанную работу другими. Выше я привел ссылки на публикации с исходниками. Если бы вы были первопроходцами - другой разговор! Но не поинтересоваться перед публикацией, а что уже сделано по этой теме - имхо, не верно. Я уж не требую в публикации приводить ссылки на аналоги, хотя на инфостарте это считается хорошим тоном.

Если бы речь шла о формате Flesh, я бы так и сделал. Этот формат достаточно навороченный, чтобы самостоятельно понять его. Что касается формата CF - ничего в нем "военного" нет. А написание компонента на C# (после того как CF-формат достаточно хорошо описан) занимает 4 часа + 4 часа на отладку.
Форматом CF я интересовался - он нигде не описан. Я нашел описание, вроде, для MD, Moxcel еще каких-то. Но CF - не нашел. Если есть такое описание, пожалуйста, дайте ссылку - я обязательно опубликую ссылку на аналогичное описание формата.
Что касается V8Update и v8cf - очень интересные ссылки. Хорошо, что вы их привели в обсуждении данной публикации. Сомневаюсь, что они мне чем-то помогут, так как С++ очень нечитабельный - его нужно смотреть под отладчиком. А запускать эти проекты под отладчиком смысла не вижу - результат уже получен.
12. Misha ⁠ (Magister) 27.01.11 12:34
Сомневаюсь, что они мне чем-то помогут, так как С++ очень нечитабельный - его нужно смотреть под отладчиком. А запускать эти проекты под отладчиком смысла не вижу - результат уже получен.

Это просто жесть... я в ауте...
Evil Beaver; cleaner_it; +2 Ответить
13. Сергей Карташев (Elisy) 27.01.11 13:01
Это просто жесть... я в ауте...

Сравните: нашел сходный код для 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 байт (С++).
14. Misha ⁠ (Magister) 27.01.11 13:57
(13)
Второй вариант будет работать быстрее на порядок, т.к. исключает лишние операции с памятью и использует меньше машинных инструкций. К тому же не использует виртуальную машину .NET, а это дополнительный тормоз.

И да, Unicode как раз всегда два байта, поэтому в корректности второго варианта у меня нет никаких сомнений.

Я согласен, что C# в данном примере читабельнее. Но это не значит что лучше. Ну и комментарии в коде рулят.
--
На то мы и программисты, чтобы писать эффективный код. А не просто читабельный.
------
Кстати, а что это за "магические числа"? Мне абсолютно непонятен их смысл. Нужно выносить такие вещи в константы и называть как-нибудь понятно. В приведенном куске кода на C++ такого нет.
ReadBytes((int)(ph.FullSize - 20 - 4));
15. Сергей Карташев (Elisy) 27.01.11 14:34
Magister пишет:
(13)
Второй вариант будет работать быстрее на порядок, т.к. исключает лишние операции с памятью и использует меньше машинных инструкций. К тому же не использует виртуальную машину .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 - не эталон инженерной мысли, но он дает возможность выбирать.
16. Misha ⁠ (Magister) 28.01.11 00:34
По быстродействию: .Net позволяет компилировать сборки в машинный код через утилиту ngen.exe, и в этом случае работа не будет вестись через виртуальную машину.
Но итоговый размер кода всё равно намного больше. Я имею ввиду весь используемый код, в т.ч. функции, вызываемые из стандартных библиотек. А значит больше количество инструкций, и больше время работы в аналогичных условиях.
По эффективности: CfInspector проектировался так, чтобы им могли воспользоваться максимальное количество людей. .Net здесь выигрывает
Не согласен. Выигрывает здесь чистый C, без плюсов.
Как мне использовать CfInspector, скажем, из Delphi 7? Или ещё лучше, на сервере под Linux, где я хочу хранить конфигурацию в git-репозитории?
Даже новичок может воспользоваться параллельными вычислениями
Согласен. Только вот не вижу я тут ничего такого, для чего параллельные вычисления должны дать прирост. Правда не вижу.
И руки поотрывать бы тем, кто писал в 1С работу с .cf и тем более с хранилищем. Это ж надо было написать настолько тормозной код!
17. Сергей Карташев (Elisy) 28.01.11 06:19
Magister пишет:
Согласен. Только вот не вижу я тут ничего такого, для чего параллельные вычисления должны дать прирост. Правда не вижу.
И руки поотрывать бы тем, кто писал в 1С работу с .cf и тем более с хранилищем. Это ж надо было написать настолько тормозной код!

Cf - это совокупность записей. В каждой записи есть тело, состоящее из массива байт. Этот массив байт нужно обработать - во многих случаях разархивировать. Если первым действием получить элементы и массивы байт, то параллельно можно обрабатывать эти массивы для каждого элемента. В публикации .AsParallel() дает прирост за счет этого.
Есть еще один момент, который не использует компонент - распараллелить обработку каждой страницы при получении элементов страницы. Как подойти - еще не знаю, да и, честно говоря, смысла не вижу - не такая это популярная тема.
18. Андрей Д. (detec) 28.01.11 12:33
ИМХО, если компонент нельзя использовать напрямую в 1С 8, без другой, платной компоненты, то его практическая ценность как самостоятельного проекта на Инфостарте стремится к нулю. Основная засада с компонентами, насколько я понял, почти полное отсутствие комплектов компонент под 8.2, которые можно было бы использовать на сервере приложения на разных аппаратных платформах.
19. Misha ⁠ (Magister) 28.01.11 12:54
Cf - это совокупность записей. В каждой записи есть тело, состоящее из массива байт. Этот массив байт нужно обработать - во многих случаях разархивировать. Если первым действием получить элементы и массивы байт, то параллельно можно обрабатывать эти массивы для каждого элемента. В публикации .AsParallel() дает прирост за счет этого.

Я не об этом говорю, это как раз понятно.
Я о том, что не в эту сторону оптимизировать надо. Это экстенсивный путь. Надо оптимизировать в сторону меньшего количества операций с памятью, кэширования всего чего только можно, чтения и распаковки данных по мере необходимости и только нужных, а не всех подряд и т.д. Тогда и распараллеливание не понадобится - и так всё будет быстро.
20. Сергей Боровик (BorovikSV) 28.01.11 19:38
Добавлю свою ложку :)

В 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. Ийон Тихий (cool.vlad4) 28.01.11 21:28
(20) наезды на .net непонятны - это технологии, все плюсы .net можно на msdn найти и их не мало, и net это не тележка с инструментами, все таки это платформа, и зачем люди пишут epf обработки, таская с собой целую тележку 1С ;) Круче разве, что крутой разработчик. Но в целом, конечно соглашусь с вами и с Magister, а данная разработка для меня представляется пока как "а можно сделать и вот так", как же это применять на практике, не знаю.
ЗЫ А дот нет как мне представляется очень хорош в крупных проектах, когда разработчиков не один и надо как можно быстрее выдавать результат, как например быстрое развертывание каких-нибудь веб решений на аспнете
22. Misha ⁠ (Magister) 30.01.11 00:47
(21) наезды на .net сводятся к тому, что это дополнительный груз для программ, и к тому же не кроссплатформенный. к тому же не самый удобный с точки зрения программиста (см. выше пример на Delphi :) ). но зато очень раскрученный, в отличие от остальных.
а насчет epf - сравнение некорректное, т.к. 1С это специализированный инструмент, а .NET позиционируется как универсальный.
23. Ийон Тихий (cool.vlad4) 30.01.11 01:50
(22) настоящей кроссплатформенностью никто похвастать не может, пока что дот нет в теории только может...раскрученный это да, но в этом есть микрософтские планы развития, существующее же решение .net представляются мне пока, что как решение в режиме совместимости со старыми приложениями - com. Насчет удобности это субъективно, кто к чему привык - вон грозные, старые дядьки привыкли к ассемблеру. Насчет дополнительного груза, как сказать...сравнение с 1С может и некорректное, но все условность...просто я хотел сказать, что все годится в каждом конкретном случае, у delphi тоже есть свои недостатки, порой старую прогу на delphi проще с нуля написать на том же delphi...
24. Misha ⁠ (Magister) 30.01.11 11:35
(23)
настоящей кроссплатформенностью никто похвастать не может
Эмм... а как же C? Если использовать "правильные" библиотеки - всё легко компилируется под Windows/Linux/BSD/MacOS/Haiku/...
Ну и про Pascal забывать не стоит, вот возьмите тот же Lazarus - из одних исходников получаем софт под Linux/Windows/MacOS.
Ну и Java таки кроссплатформенна, хотя тормоз тот ещё.
25. Сергей Карташев (Elisy) 31.01.11 07:25
BorovikSV пишет:
Добавлю свою ложку

Delphi - это отдельная история. Последние версия Delphi, насколько мне известно, полностью поддерживает .Net. Значит и разработчики Delphi в нем что-то нашли.
Delphi 8 for the Microsoft .NET framework
Поэтому согласен, конструкция
byte[] idBytes = ReadBytes((int)(ph.FullSize - 20 - 4));
Encoding u16LE = Encoding.Unicode;
ir.Id = u16LE.GetString(idBytes); 

на Delphi 8 будет выглядеть один в один.
26. Сергей Карташев (Elisy) 31.01.11 07:36
Magister пишет:

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

.Net, думаю, скоро будет встроен в Windows и устанавливаться автоматически (не помню, может в Windows 7 и 2008 так уже и есть). C DirectX были такие же сложности - пакет установки объемный, нужно отслеживать версии. В Windows 7 идет встроенным DirectX 11, и многие проблемы снялись сами собой.
Мне связка .Net + C# очень нравятся - эта связка позволяет писать быстро программы повышенного качества. Сообщество .Net-просто огромное, и как следствие решения для большинства проблем уже найдены. MSSQL 2005/2008 не стесняются пользоваться .Net, хотя это продукты, изначально нацеленные на быстродействие.
27. Сергей Карташев (Elisy) 31.01.11 08:18
Magister пишет:
(23)

На голом С достаточно легко написать кроссплатформенное решение "Hello World!". Все приложения, которые сложнее, потребуют значительных затрат моего времени. Как получать/записывать данные? У MS есть ODBC, ADO - у Linux наверняка тоже что-то есть, но не ODBC/ADO. Значит нужно мне самому описывать разные подходы для разных ОС. Тоже самое интерфейс пользователя - у MS DirectX (для WPF-варианта), у Linux не DirectX - мне самому писать 2 интерфейса для 2х ОС?
Недавно на Mista.ru был интересный вопрос - какой аналог COM у Linux - оказалось его нет.
Мое мнение: кроссплатформенность хороша, когда пишется изолированное приложение. В современном мире такого не бывает. Нужно писать хорошо под одну платформу, используя ее сильные стороны. Если есть спрос, можно переписать его для другой платформы. Для .Net framework есть альтернатива под Linux - это проект Mono.
28. Ийон Тихий (cool.vlad4) 31.01.11 10:23
Добавлю -, если C такой кроссплатформенный, нафига микрософту interix, чего это они мучаются с портированием хороших сишных программ с никсов? Ответ наверное кроется в абсолютном различии самих платформ, ...ну блин тогда все языки кроссплатформенны, ...мы же говорим не про существование различных диалектов языков на различных платформах (delphi, этот freepascal c надстройкой лазарус), а про теоретический перенос приложения в идеале даже перекомпиляции не требующий - ну так этого ни у кого нет. Насчет net framework - одна из попыток облегчить жизнь разработчику, начиная с xp(ну по крайней мере с висты) идет в составе дистрибутива ОС, насчет того интегрирована в ОС, сомневаюсь - для меня интеграция это когда ОС уже жить без этого не сможет, а винда может обходится без нета. Но судя по проекту сингулярити, микрософт нацелен использовать идею нета основательно. Насчет Delphi - да 8 была ориентирована на net - по моему чуть ли не одной из первых (и я бы не сказал, что удачной), потом микрософт дал ей по лапам(от делфи еще разработчик насколько я помню в нет перешел), и вроде проект немного приостыл. Затем после многочисленных перекупок, покупок - появились delphi .prism, hydra и даже бесплатный free pascal engine. Технологии. Это же хорошо. Конечно и про С забывать не стоит. Но это как автомобили, - каждый выбирает для своих целей.
___________
ЗЫ опечатка не free pascal engine, а конечно же pascal script, вроде как его использует redline для исы и форефронта - но могу и ощибатся
ЗЫ сорри за непростительно печатание анг буков - русскими - тороплюсь....
29. Misha ⁠ (Magister) 31.01.11 21:10
(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. Ийон Тихий (cool.vlad4) 31.01.11 21:27
(29) Я знаю, что не Delphi, пришлось писать на лазаре как-то, не понравилось честно, идея хороша, но это больше для учебы и студенчества подходит. Я имел ввиду, что кроссплатформенность в идеале недостижима, к примеру видите какие вопросы задают- есть ли аналог com в linux? Есть ли велосипеды у марсиан, может и есть, но не велосипеды. Платформы настолько различные между собой, что кроме как придумывание оберток, над-оберток мне кажется ничего не придумать. Насчет бизнес-логики, да соглашусь. Насчет легко переносимости, это прямо пропорционально сложности проекта и, все возрастающих зависимостей от родной платформы. А еще знаете как - я просто не силен в С, а тут модный дотнет, с синтаксисом, после моего засиживания на delphi, очень приятным - потому мое мнение предвзято. А Elisy - уважаю, все равно молодец, может компонента и несет в себе скорее теоретический смысл, но кто знает - может это начало чего-то большего.
31. Сергей Карташев (Elisy) 01.02.11 11:34
Magister пишет:
(27) А вы писали кроссплатформенные приложения на 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. Misha ⁠ (Magister) 01.02.11 12:25
(30) Вобщем согласен.

(31) 1С как раз сейчас этот стереотип разрушает. И ИМХО скоро будет 1С - сервер под Linux, СУБД - DB2 (или даже Oracle). У кого денег поменьше - у тех PostgreSQL.
А Mono... теоретически да, аналог. Только вот присмотритесь внимательнее, что он поддерживает. По крайней мере WPF там нет и врядли появится. Как и многое другое.
33. Сергей Боровик (BorovikSV) 02.02.11 00:33
Elisy пишет:(25)
Delphi - это отдельная история. Последние версия Delphi, насколько мне известно, полностью поддерживает .Net. Значит и разработчики Delphi в нем что-то нашли.


Вам неправильно известно. Последняя версия DELPHI - RAD STUDIO XE. К NET не имеет почти никакого отношения.
Знающие подтвердят, что среда разработки очень "похорошела". Но попытки миграции в сторону NET (после выхода версии DELPHI 8 .NET) больше не происходили.
34. Ийон Тихий (cool.vlad4) 02.02.11 00:49
(33) Подтверждаю, но я не стал придираться, смысл то мне был понятен....скорее всего был спутан Delphi .Prism, который предлагается той же кампанией, но это отдельный продукт, имеющий несколько другое происхождение - скажу лишь, что он тоже относится к объект паскальным языкам(язык oxygene).
35. Сергей Карташев (Elisy) 02.02.11 06:32
BorovikSV пишет:
Вам неправильно известно. Последняя версия DELPHI - RAD STUDIO XE. К NET не имеет почти никакого отношения.
Знающие подтвердят, что среда разработки очень "похорошела". Но попытки миграции в сторону NET (после выхода версии DELPHI 8 .NET) больше не происходили.

Значит у меня устаревшие данные: Статья про будущее Borland, очень интересно

"Вообще говоря, во всех презентациях Delphi 8 называлась как версия Delphi 8 for .Net, и всячески говорилось, что это следующий шаг развития Delphi. Аудитория пыталась вопросами прояснить, как быть со старыми приложениями, написанными на предыдущих версиях Delphi. Но Сергей Орлик не сдавал позиции, отвечая уклончиво, говоря, что потребуется минимум изменений для переноса под .Net и т.п., пока не получил вопрос в лоб:

В: Имеется ли возможность разрабатывать на Delphi 8 приложения под Win32 для Windows 95?
О: С Delphi 8 поставляется в комплекте Delphi 7. (Дружный смех в зале)"

Если есть у вас ссылки на более свежее описание стратегий Delphi и CBuilder, пожалуйста, поделитесь. Мне эта тема тоже интересна.
36. Ийон Тихий (cool.vlad4) 02.02.11 10:21
(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 (в основном связанные с облаками) в роликах http://www.delphifeeds.com/go/s/71336
Ну и на ихнем сайте www.embarcadero.com, скажу сразу дотнета там нету. ДотНет у них есть в Delphi .Prism, язык Oxygene
37. Ийон Тихий (cool.vlad4) 02.02.11 10:30
У Delphi Prism вообще история интересная (советую погуглить),прототипом был Object Pascal-ный язык Chrome - развивалась насколько я помню отдельно от Delphi кампанией RemObjects Software - появился язык (для CLR) Oxygene, затем после многочисленных изменений в кампаниях, покупок - стал Delphi Prism - полноценный паскальный для дотнета, совместимости с Delphi никакой. Установка возможна как на радстудию Delphi, так и на Visual Studio.
38. Ийон Тихий (cool.vlad4) 02.02.11 10:35
Добавлю, что в России популярности последние продукты Delphi по всей видимости не получили. Либо все остались верны старым версиям (в основном 6,7 и 2007), либо перешли на дотнет.
39. Сергей Карташев (Elisy) 02.02.11 11:54
(36)(37)(38)
Спасибо огромное за такое подробное описание. Вижу, у Borland не все так гладко, нет стабильности и четкой стратегии.
40. Сергей Боровик (BorovikSV) 02.02.11 19:10
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, научится еще многим вкусностям о которых даже не подозреваем.
41. cruse 07.02.11 18:53
В свое время реверсил формат .1cd

Приятно что есть люди, которым близка тематика. То что конфигуратор не имеет своего API удручает, на больших проектах обеспечивать качество врукопашную, когда код постоянно модифицируется, любого выматает.
42. Сергей Карташев (Elisy) 21.02.11 07:02
В компонент добавлена возможность чтения образа из базы данных MSSQL. Некоторые свойства были переименованы и стали совпадать с названиями полей в таблицах базы данных.
43. Misha ⁠ (Magister) 01.04.12 21:35
(17)
Таки нашел времени выложить свою наработку:
http://forum.infostart.ru/forum24/topic51772/message637585/#message637585
Пока распаковывает не всё - видимо, где-то ошибся при чтении данных, разбитых на несколько блоков, но по скорости получилось, как мне кажется, неплохо.
Написано на Lazarus.
Как будет время довести до ума - доведу и выложу публикацией.
44. Борис Илов (ilov_boris) 09.01.13 21:58
Спасибо большое. Очень помог ваш компонент.
45. Сергей Карташев (Elisy) 10.01.13 09:38
(44) ilov_boris,
Данная статья устарела. Отдельно компонент больше не поддерживается. Он полностью вошел в отдельную сборку
Elisy.MdInternals и расширен возможностью записи.
На основе нового компонента создана разработка:
http://infostart.ru/public/103834/
46. Борис Илов (ilov_boris) 10.01.13 14:25
(45) Elisy, а MdInternals также никаких доп. библиотек не требует?
47. Сергей Карташев (Elisy) 10.01.13 15:28
(46) ilov_boris,
MdInternals, вроде, не должна требовать библиотек, кроме Elisy.NetBridge, если доступ через 1С.
"Выковырять" ее можно из макета файла к вышеупомянутой статье.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа