visual studio - Expanding media capabilities of Win Embedded CE 6.0 -

i have embedded device wince 6.0 os. manufacturer provides ide 3rd party development it. ide pretty allows nothing else than

• .net 3.5 compact framework scripting that's invoked various events main application
• adding files device.

the included mediaplayer seems using directshow , os has media codec mpeg-1 encoded video playback. my goal to able play media encoded other codecs well inside main application.

i've managed use directshownetcf (directshow wrapper .net compact framework) , playback mpeg-1 encoded video.

i'm totally new stuff , have tons of (stupid) questions. i'll try narrow them down:

• the os based on wince, far i've understood, it's customized version of (via platform builder). "correct way" of developing afterwards use sdk manufacturer provides. right? in case, sdk extremely limited , tightly integrated ide noted above. however, .net cf 3.5 capable interop possible call native libraries -as long compiled correct platform.

• compiled code pretty instructions processor (assembler code) , compiler chooses correct instructions based on target processor setting. there's pe-header defines under platform program meant run. if target "helloworld.exe" (does nothing returns specific exit code) x86 , compile vc, should work?

• if pe-header in fact problem, possible setup wince without sdk? need whole sdk creating simple executable uses base types? i'm using vs2010, doesn't support smart device dev anymore , i'd hate downgrade testing purposes.

• above questions prequel actual idea: porting ffmpeg/ffdshow wince. exists, not targeted nor built intel atom. comments?

• if native implementation not possible , end implementing specific codec c#...well quite massive task. having choose c# on native, run problems codec performance? mean.. c# slower?

thank you.

i've not seen oem shipped own ide, it's possible. shouldn't change how apps can created, however. it's possible they've done lot of work make sure things ide work, serious amount of work not benefit, i'd think it's unlikely.

as specific questions:

• the os is windows ce, not "based on" it. os is, however, componentized, not pieces going available. sdk provides mechanism filter out isn't available. can use sdk targets right processor architecture, if app calls library isn't in os, you'll @ least error. managed code not relevant because cf isn't componentized. if it's there, , cf app can run (and if it's not, can install after fact). means if platform supports cf, can write cf app , run it. app can call native stuff via p/invoke (unless, of course, os creator decided add security prevent that. possible in os, though i've never seen implemented).
• yes, compiled code "instructions". native, yes, processor instructions. managed, msil instructions managed runtime in turn converts processor instructions @ jit time. if target arm platform, cannot use x86 compiler. broadly speaking, need use correct microsoft compiler support windows ce, , call compiler proper switches tell not processor architecture, target os because linking needs done different os-level apis , c runtimes. short of platform, need use visual studio 2008 pro.
• for native apps, need sdk targets same os version (ce 6.0) , processor architecture (e.g. armv4i). having match os feature set useful not requirement. managed code, can use sdks ship studio because managed code not processor-dependent. still, have go studio 2008 because 2010 doesn't have wince compilers.
• if you've found existing library, can try use it. things might impede progress a) it's unlikely use sdk have have create new project files (painful, workable) , b) if uses features not available in os, you'd have work around those. if you're missing os features, you're out of luck if has media player , codec, suspect you'll ok.
• don't implement in managed code. seriously, don't it. you? yes. performance made same except avoid gc stuttering you're going have create own memory manager. amount of work involved in path very, large.