none
Старые типы данных Microsoft RRS feed

  • Вопрос

  • Сталкивался ли кто-нибудь с задачей считывания и записи данных, записанных в старых форматах данных Microsoft?
    Я столкнулся с Microsoft Basic Floating Point, форматом данных с плавающей точкой из 90-х годов, реализованных в первых версиях Basic.
    Понятно, что написал соответствующие методы, которые его читают и конвертируют в стандартный Double, но как это делать правильно с точки зрения Microsoft ? Ведь поддержка работы со старыми форматами (чтение -запись преобразование) на уровне среды весьма желательна ?
    Почитал результаты поиска по MSDN, понял, что в СLI для этих действий функций нет. Все пишут свои методы. Ошибаюсь ?

    речь вот об этих форматах http://support.microsoft.com/kb/45166
    и о вот таких функциях http://support.microsoft.com/kb/45166

    • Перемещено Tagore Bandlamudi 2 октября 2010 г. 22:14 MSDN Forums consolidation (От:Разработка Windows-приложений)
    5 ноября 2009 г. 8:14

Ответы

  • Да, необходимо писать свои функции.Вот пример, посмотрите весь тред:
    Microsoft Basic floating point format to IEEE floating point format
    • Предложено в качестве ответа I.Vorontsov 5 ноября 2009 г. 8:46
    • Помечено в качестве ответа GL88 5 ноября 2009 г. 11:46
    5 ноября 2009 г. 8:45
  • В .net есть стандарный способ подключения dll - DllImportAttribute
    Достаточно написать 4 строчки - и фунции dll станут функциями .net.

    Microsoft вполне логично выбрала путь "использовать старое напрямую" вместо "переписать весь старый код по новый фреймворк". Одна из основных фич .net - interopability, возможность не переводить на .net все подряд.

    Кстати, баги в visual studio можно постить на http://connect.microsoft.com/ . Если баг действительно мелкий, организиционный, касается не только вас и не упирается в нежелание использовать существующую dll - его скорее всего исправят.
    • Помечено в качестве ответа I.Vorontsov 5 ноября 2009 г. 12:38
    5 ноября 2009 г. 12:34
  • Понял. Реализовал свои функции.
    Вообще грустно, что на уровне CLR нет поддержки "родных" форматов Microsoft, обеспечивающих рациональное использование ранее созданного кода. Я не говорю об операциях, но вот функции чтения, записи и преобразования в новые форматы стоило бы реализовать. Все таки частичная совместимость сверху вниз сохранится.
    В приведенном Вами примере, кстати, речь идет о Metastock'ковском приложении. И этот формат используется до сих пор и с большой интенсивностью. Так что "родная" поддержка в достаточном объеме в .Net старых форматов целесообразна.
    • Помечено в качестве ответа GL88 5 ноября 2009 г. 9:16
    5 ноября 2009 г. 9:16

Все ответы

  • Да, необходимо писать свои функции.Вот пример, посмотрите весь тред:
    Microsoft Basic floating point format to IEEE floating point format
    • Предложено в качестве ответа I.Vorontsov 5 ноября 2009 г. 8:46
    • Помечено в качестве ответа GL88 5 ноября 2009 г. 11:46
    5 ноября 2009 г. 8:45
  • Понял. Реализовал свои функции.
    Вообще грустно, что на уровне CLR нет поддержки "родных" форматов Microsoft, обеспечивающих рациональное использование ранее созданного кода. Я не говорю об операциях, но вот функции чтения, записи и преобразования в новые форматы стоило бы реализовать. Все таки частичная совместимость сверху вниз сохранится.
    В приведенном Вами примере, кстати, речь идет о Metastock'ковском приложении. И этот формат используется до сих пор и с большой интенсивностью. Так что "родная" поддержка в достаточном объеме в .Net старых форматов целесообразна.
    • Помечено в качестве ответа GL88 5 ноября 2009 г. 9:16
    5 ноября 2009 г. 9:16
  • Уважаемый GL88, думаю Вы согласитесь, что было бы более правильно и корректно пометить ответ Ивану, ибо ссылку все же предоставил Вам он.
    Поможем друг другу стать лучше! Отметим правильные ответы и полезные сообщения!
    5 ноября 2009 г. 11:01
  • На этот счет надо напоминать людям - часто либо вобще не отмечают ответ, либо отмечают не ответ:)
    5 ноября 2009 г. 11:08
  • Спасибо за совет, сделал, пометил.
    Но на самом деле ответа нет.
    Это в общем мелкий организационный баг Visual Studio. И теперь понятно, что обходить его надо собственным кодом.

    5 ноября 2009 г. 11:48
  • Вы были не уверены что это и спросили поэтому на форуме. И вам дали вполне определенный ответ - а вы говорите ответа нет.
    5 ноября 2009 г. 11:51
  • Я предполагал такую ситуацию, но на всякий случай спросил на форуме.
    Свои методы написал до обращения на форум. Проверил по MSDN, решил проверить и на форуме.
    Уж больно ответ невероятный.
    Жаль, что адекватную поддержку совместимости со старыми продуктами Microsoft каждый делает своими руками.
    Имхо, работы там чуть, но стоило бы сделать в .Net соответствующие функции.
    dll вроде есть от Microsoft, смотрите ссылки в исходном посте, а функций в .Net - нет.
    5 ноября 2009 г. 12:04
  • В .net есть стандарный способ подключения dll - DllImportAttribute
    Достаточно написать 4 строчки - и фунции dll станут функциями .net.

    Microsoft вполне логично выбрала путь "использовать старое напрямую" вместо "переписать весь старый код по новый фреймворк". Одна из основных фич .net - interopability, возможность не переводить на .net все подряд.

    Кстати, баги в visual studio можно постить на http://connect.microsoft.com/ . Если баг действительно мелкий, организиционный, касается не только вас и не упирается в нежелание использовать существующую dll - его скорее всего исправят.
    • Помечено в качестве ответа I.Vorontsov 5 ноября 2009 г. 12:38
    5 ноября 2009 г. 12:34
  • Спасибо за ответ. Базовая dll от Microsoft есть, по использованию метода я почитаю. В принципе возможно закрытие не только этой проблемы, но и ряда других.
    Однако уже которую версию Visual Studio нет таких элементарных встроенных функций, с примерами использования. Думаю, это в определенной степени политика, направленная на производителей программного обеспечения, с целью перехода на новые версии. Попробую оформить dll указанным методом, посмотрю на реальное применение.
    Для остальных замечу, что есть еще и функции dll от Equis, пакет MSFL, выполняющий функции чтения файлов, и нужных преобразований. Однако запись - уже более сложно, в dll Equis функций записи нет. Поэтому мне они не подходят. Что, в общем, правильно с точки зрения разработки системы.
    Но помимо узких специфичных задач Equis есть и остальные пользователи, которые часто сталкиваются с подобными старыми программами, в основном научный сектор.

    5 ноября 2009 г. 18:07