Are there any boost binaries available for Windows Phone 8? I'm mostly looking for the basic stuff such as shared_ptr and threading. Note that threading needs both to be build for ARM and use the correct platform calls, while shared_ptr works right of the bat.
If not, how do I build boost::thread for Windows Phone 8?
Update: I checked out the WinRT API and the boost source. The windows threading in boost relies heavily on Thread Local Storage (TLS), but this is not supported on WinRT. However, there seems to be some Fiber Local Storage (FLS), but it's not quite the same thing.
There is an official page on this dated of 18 Jul 2014, confirming that some of the libraries in Boost use APIs that aren’t available in Windows Store and Phone applications, and as so saying We’ve made improvements to the Boost build system to support targeting the Windows Runtime for Windows Store and Phone.
I'm compiling against some static libraries that rely on boost so I don't think that's an issue at all.
As of Visual Studio 2013 Update 4, you can compile source that uses the TLS APIs since they are implemented as inlines that forward to the FLS APIs (which are Store-compliant). Obviously pre-compiled binaries won't work since they will try and bind to TLS directly.
FYI the reason TLS is deprecated / banned is because there is the potential to leak memory if a thread terminates. If you use TLS APIs in Store apps they will have the same issue of potential memory leaks (the FlsCallback provided to FlsAlloc is null) so consider moving to TLS and providing a cleanup function.
Related
I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than
.NET 3.5 Compact Framework scripting that's invoked from various events from the main application
Adding files to the device.
The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.
I've already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.
I'm totally new with this stuff and I have tons of (stupid) questions. I'll try to narrow them down:
The OS is based on WinCE, but as far as I've understood, it's actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.
Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there's the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work?
If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK? Do I REALLY need the whole SDK for creating a simple executable that uses only base types? I'm using VS2010, which doesn't even support smart device dev anymore and I'd hate to downgrade just for testing purposes.
Above questions are prequel to my actual idea: Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments?
If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance? I mean.. is C# THAT much slower?
Thank you.
I've not seen an OEM that shipped their own IDE, but it's certainly possible. That shouldn't change how apps can created, however. It's possible that they've done a lot of work to make sure only things from their IDE work, but that would be a serious amount of work for not that much benefit, so I'd think it's unlikely.
As for your specific questions:
The OS is Windows CE, not "based on" it. The OS is, however, componentized, so not all pieces are going to be available. An SDK generally provides a mechanism to filter out what isn't available. You can actually use any SDK that targets the right processor architecture, but if your app calls into a library for something that isn't in the OS, then you'll get at the very least an error. For managed code this is all not relevant because the CF isn't componentized. If it's there, and CF app can run (and if it's not, you can often install it after the fact). This means that if the platform supports the CF, then you can write a CF app and run it. That app can then call native stuff via P/Invoke (unless, of course, the OS creator decided to add security to prevent that. This is possible in the OS, though I've never seen it implemented).
Yes, compiled code is just "instructions". For native, yes, they are processor instructions. For managed, they are MSIL instructions that the managed runtime in turn converts to processor instructions at JIT time. If your target is an ARM platform, you cannot use an x86 compiler. Broadly speaking, you need to use the correct Microsoft compiler that support Windows CE, and call that compiler with the proper switches to tell it not only the processor architecture, but also the target OS because the linking that needs to be done will be different for OS-level APIs and even the C runtimes. The short of this is that for your platform, you need to use Visual Studio 2008 Pro.
For native apps, you need some SDK that targets the same OS version (CE 6.0) and processor architecture (e.g. ARMv4I). Having it match the OS feature set is also useful but not a requirement. For managed code, you can just use the SDKs that ship with Studio because managed code is not processor-dependent. Still, you have to go back to Studio 2008 because 2010 doesn't have any WinCE compilers.
If you've found an existing library, then you can try to use it. Things that might impede your progress are A) it's unlikely to use an SDK you have so you probably have to create new project files (painful, but workable) and B) if it uses features not available in your OS, then you'd have to work around those. If you're missing OS features, you're probably out of luck but if it already has a media player and codec, I suspect you'll be ok.
Don't implement this in managed code. Seriously, just don't do it. Could you? Yes. Performance could probably be made to be nearly the same except to avoid GC stuttering you're going to have to basically create your own memory manager. The amount of work involved in this path is very, very large.
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
Update1: 2012-12-17:
While native C++ still isn't officially supported for Windows Phone 7, Windows Phone 8 now supports native C++ code so you can more easily port your existing C++ codebase(s) to Windows Phone 8 (as well as Windows 8 and Windows desktop apps).
While there isn't 100% compatibility between the Windows8/Phone8 platforms and API's right now, I expect the two platforms to become increasingly integrated over the next couple of releases.
This is especially true now that one of the key barriers to closer cooperation between Windows and other groups at Microsoft recently left the company ;)
Update2: 4/15/2014:
As per the recent announcements at //BUILD/ 2014, you can now start building "universal" apps in C++ & XAML, C#/VB & XAML or JavaScript & HTML that will run on Windows 8.1, Windows Phone 8.1 and Xbox One! For more details on building Windows Phone 8.1 Universal Apps, read this article.
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port.
We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
It is on the horizon finally!
So a survey sent to windows phone developers about their future
development preferences and XNA isn't mentioned once in the Survey (A
survey sent to windows phone developers - did I mention that)
They do however ask:
How would you prefer to use C++ in your mobile apps/games?
Develop apps/games that are C++ from top to bottom (UI, business logic, and platform
APIs)
Use C++ for business logic and then write platform abstraction layer
Use C++ for business logic use 3rd party runtime engines
I don’t want to use C++
wxWdgets is a cross-platform library that includes support for all the major windows versions, but I can't find anywhere in the wxWidgets documentation that says anything about the portability of a single MSW (windows) build of the wxWidgets library across different windows versions. Assuming my core app just uses vanilla C++ (and perhaps the least common denominator of win32 apis available on all platforms) except for wx functions, would linking statically against a single version of the wxWidgets library produce a binary that would run across Win2K, XP, Vista, and windows 7? Would that library need to be built on win2K (the "least featureful" platform?), or would building it on XP also work? Any hints or pointers would be appreciated!
You can build the application on any OS version you want, this doesn't affect the application compatibility with different Windows versions. You can even cross-compile Windows applications on another OS.
The important thing is the selection of API calls that the application references. Any functions linked at loadtime need to be present in the OS, while libraries or API functions that are delay loaded don't affect the compatibility, as long as the application handles the errors gracefully.
The stable wxWidgets version 2.8 is compatible with at least Windows 2000 and all later versions (you could even target Windows 9X if you use the non-Unicode build of the library), it delay loads all functions that are not available in Windows 2000 (for example theme support, introduced with XP). You can be sure that the application runs, but there may be things that don't work on Windows 2000 (for example transparent PNGs).
There may be additional minimum OS version requirements imposed by the development environment. Newer Visual C++ versions for example may require the C runtime to be installed on older OS versions, and there may be a minimum supported version. This however is independent of wxWidgets being used in the program or not.
Yes, wx binaries are portable across XP--7 range (and the same binary should also write on systems as ancient as 95 if you don't use Unicode or use MSLU but so few people use those nowadays (thankfully) that this might have actually got broken without anybody noticing). wxWidgets loads any functions not present in the system DLLs on all Windows versions dynamically, i.e. via GetProcAddress(), and uses reasonable fallbacks for the older systems.
Can I write and compile code for this on XP? We have utilities for our apps that use activesync and now will be adding Vista/WMDC - and I was hoping I don't have to have another development OS (Vista) to develop and compile on.
I have not seen much documentation for the API for WMDC - can someone point me to some useful references for it?
hummm... ActiveSync, so Windows Mobile am I right?
all you need is the SDK and Visual Studio (well, this last you don't need cause you can compile everything using the command line, but, very nice to have for such applications)
there are plenty of SDKs for what you need, for example PocketPC, Windows Mobile, etc...
the sdk contains everything you need to build, compile and deploy an application, works fine on windows XP (what I currently use) and with ActiveSync, you can even debug the application in the device ;)
added:
unfortunatelly there is no SDK for the WMDC. The only thing you have are the 4 libraries in the %WinDir%\Windows Mobile. It contains 4 libraries named as "Microsoft.WindowsMobile.*.dll". Additionally you don't get any documentation on the libraries themselves which makes it hard to use.
As you use the RAPI (I think by using the OpenNETCF library) most of the applications shall still run under WMDC as the included RAPI seems to be backward compatible. The included RAPI itself is in a new version.
taken from MSDN forum
I hope this helps for the moment.