Расширение возможностей мультимедиа Win Embedded CE 6.0

Question

У меня есть встроенное устройство с WinCE 6.0 в качестве ОС. Производитель предоставляет IDE для разработки сторонних разработчиков. IDE в значительной степени не позволяет ничего другого, чем

• .NET 3.5 Compact Framework сценариев, который вызывается из различных событий из основного приложения
• Добавление файлов на устройство.

Включенный медиаплеер, кажется, использует DirectShow, а ОС имеет медиакодек только для воспроизведения видео с кодировкой mpeg-1. Моя цель - иметь возможность воспроизводить медиа, закодированные с помощью некоторых других кодеков, а также внутри этого основного приложения.

Я уже успел использовать DirectShowNETCF (оболочка DirectShow для .NET Compact Framework) и успешно воспроизвести видео с кодировкой mpeg-1.

Я совершенно новый с этим материалом, и у меня есть тонны (глупых) вопросов. Я буду стараться сократить их:

• ОС основана на WinCE, но, насколько я понял, это на самом деле всегда есть адаптированная версия этого (с помощью Platform Builder). Только «правильный способ» разработки чего-либо для этого заключается в использовании SDK, который обычно предоставляет производитель. Правильно? В моем случае SDK чрезвычайно ограничен и плотно интегрирован в IDE, как указано выше. Тем не менее, .NET CF 3.5 способен к взаимодействию, поэтому его можно вызывать родные библиотеки - до тех пор, пока они скомпилированы для правильной платформы.

• Скомпилированный код - это в значительной степени просто инструкции для процессора (код ассемблера), и компилятор выбирает правильные инструкции, основанные на настройке целевого процессора. Также есть PE-заголовок, который определяет, под какой платформой должна запускаться программа. Если я нацелен на свой «helloworld.exe» (ничего не возвращает только код выхода) на x86 и компилирует его с помощью VC, должен ли он работать?

• Если PE-заголовок на самом деле является проблемой, возможно ли установить WINCE без SDK? Мне действительно нужен весь SDK для создания простого исполняемого файла, который использует только базовые типы? Я использую VS2010, который даже не поддерживает интеллектуальных устройств, и я бы не хотел понижать рейтинги только для целей тестирования.

• Вышеперечисленные вопросы являются приквелом к ​​моей фактической идее: Портирование ffmpeg/ffdshow для WinCE. Это фактически уже exists, но не предназначено и не предназначено для Intel Atom. Комментарии?

• Если нативная реализация невозможна, и я в конечном итоге реализую некоторый определенный кодек с C# ... ну, что, вероятно, будет довольно масштабной задачей. Но нужно ли выбирать C# над native, могу ли я столкнуться с проблемами с производительностью кодека? Я имею в виду .. это C# THAT намного медленнее?

спасибо.

Answer 1

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

Что касается ваших конкретных вопросов:

• ОС является Windows CE, а не "на основе" его. ОС, однако, компонентная, поэтому не все части будут доступны. SDK обычно предоставляет механизм для фильтрации того, что недоступно. Фактически вы можете использовать любой SDK, который ориентирован на правильную архитектуру процессора, но если ваше приложение вызывает в библиотеке что-то, чего нет в ОС, вы получите как минимум ошибку. Для управляемого кода это все не имеет значения, потому что CF не является компонентным. Если он есть, и приложение CF может запускаться (и если это не так, вы можете часто устанавливать его после факта). Это означает, что если платформа поддерживает CF, вы можете написать приложение CF и запустить его. Это приложение может затем вызвать родной материал через P/Invoke (если, конечно, разработчик ОС не решился добавить защиту для предотвращения этого. Это возможно в ОС, хотя я никогда не видел его реализовано).
• Да, скомпилированный код - это просто «инструкции». Для native, да, это инструкции процессора. Для управляемых - это инструкции MSIL, которые управляемая среда выполнения, в свою очередь, преобразуется в инструкции процессора во время JIT. Если ваша цель - платформа ARM, вы не можете использовать компилятор x86. Вообще говоря, вам нужно использовать правильный компилятор Microsoft, который поддерживает Windows CE, и вызывать этот компилятор с соответствующими коммутаторами, чтобы рассказать ему не только о архитектуре процессора, но и о целевой ОС, потому что связь, которая должна быть выполнена, будет отличаться для API-интерфейсы уровня OS и даже время выполнения C. Короче говоря, для вашей платформы вам необходимо использовать Visual Studio 2008 Pro.
• Для родных приложений вам нужен SDK, предназначенный для одной и той же версии ОС (CE 6.0) и архитектуры процессора (например, ARMv4I). Совпадение с набором функций ОС также полезно, но не обязательно. Для управляемого кода вы можете просто использовать SDK, которые поставляются с Studio, потому что управляемый код не зависит от процессора. Тем не менее, вам нужно вернуться в Studio 2008, потому что в 2010 году нет компиляторов WinCE.
• Если вы нашли существующую библиотеку, вы можете попробовать ее использовать. Вещи, которые могут помешать вашему прогрессу, - это A) вряд ли вы будете использовать SDK, который у вас есть, поэтому вам, вероятно, придется создавать новые файлы проектов (болезненные, но работоспособные) и B), если он использует функции, недоступные в вашей ОС, тогда у вас будет чтобы обойти их. Если вам не хватает функций ОС, вам, вероятно, не повезло, но если у него уже есть медиаплеер и кодек, я подозреваю, что все будет в порядке.
• Не используйте это в управляемом коде. Серьезно, просто не делай этого. Могли бы вы? Да. Производительность, вероятно, может быть почти одинаковой, за исключением того, что вы избегаете GC-заикания, которое вам нужно будет создать в вашем собственном менеджере памяти. Объем работы, связанной с этим путем, очень, очень большой.