I have a cpp project, that i try to build in vs2008, for Windows CE on my car stereo.
I only have the options in vs2008 to build for Windows Mobile 6 pro or windows mobile pocket pc 5. But none of these options builds a working exe file.
When downloading a precompiled file, it works fine.
So my questinon is how do i build this project?
Which packages do i have to install, in order to have the right build options?
As already suggested by Luka the best option is to have an SDK for that specific device.
If the device manufacturer does not provide it you should at least check the CPU type and Windows CE version to try to get a compatible SDK. In this case you may reference some functions that are not actually available on the device or not being able to reference some that are actually available, but this should not prevent you from doing a build.
Related
Target: Determine working way to publish Qt5 application in Windows 10 Store both for Windows 10 Desktop and Mobile device families.
Issue: Qt5 WinRT provides separate Qt builds for x86, x64 and armv7 platforms, where each build can auto-generate Visual Studio solution only for specific platform (qmake.exe -tp vc YourProject.pro). So it's possible to have separate .appxupload bundles (generated by Visual Studio) for x86 and armv7, but it's not possible to publish both of them in the Windows Store at the same time.
Additional info: On publishing of C# UWP application Visual Studio creates separate appx packages for all selected platforms(x86, x64, arm) and puts them into the one .appxupload package to be uploaded to the Windows 10 Store. But it looks like because qmake can't create Visual Studio project file for multiple platforms, it's not possible to use C# UWP approach.
I hope that someone already uploaded to Windows 10 Store Qt apps and can share working way of doing this with multiple platforms support.
Based on your description, Qt5 WinRT provides separate Qt builds for x86,x64, and ARM platform, when you create package for your project, you may need to select one architecture at a time, like the screenshot below.
When you have created three different platform packages, you can upload these package and select apposite devices，different operating systems can run different types of packages.
Hope it is help to you.
So far I was able to find only following solution:
It's needed to create different appxupload packages files to be uploaded into Windows 10 Store - one package for armv7 platform (where in Package.appxmanifest it's required to put target devices family as Windows.Mobile) and one package for x86 platform(where in Package.appxmanifest it's required to put target devices family as Windows.Desktop).
<TargetDeviceFamily Name="Windows.Mobile" />
Also the packages should has different application version.
Such 2 packages can be uploaded into one Submission application record at Developer Dashboard and will not conflict with each other.
In case if to try upload both packages with "Windows.Universal" as target device family, MS Store Dashboard complains that packages has similar "Neutral" platforms (even if different platforms were specified in app manifest). Also if both packages are of similar version, you will get web page error on finish of packages uploading.
In case if you will put the support of platform that is not part of the package, such submission will be failed during certification.
I'm attempting to use Visual C++ cross platform features to write an SDL 2 app for Windows, Windows Universal, iOS, Android and Linux. I have one project for each platform now I want to abstract the SDL stuff to a common project that each platform project will reference with each project supplying the appropriate SDL libs for the platform through the linker.
Is there a project type in VS that actually allows me to do this? I was hoping the shared items project would do the trick, but I doubt thats the one. There does appear to be some form of shared library for iOS and Android, but it doesn't look like that extends to Linux and Win32.
Thanks,
To make a successful cross-platform application with SDL2, you should, in first place, use a compiler that's available on both platform. Because, you will need to compile a binary for each platform. SDL2 seems to support IOS and Android out of the box, but I don't know how deployment is done for the mobile OS. You can still use Visual Studio with CMake or a Makefile and use another compiler instead of Visual C++ to support a cross-platform build, like g++ (mingw32 on windows) or Clang.
I am Windows developer accustomed to Visual Studio Community. Now I'm starting to develop for Linux on both embedded devices (Raspberry Pi, C.H.I.P) and PCs.
I have found that Visual Studio has two options to develop for Linux:
VisualGDB - Visual Studio extension for cross-compiling and remote debugging, but it costs too much for my current budget
the brand new Microsoft extensions: Visual C++ for IoT Development and Visual C++ for Linux Development, but they are buggy, they copy every file on every build and they are difficult to configure "Linux way" (no full make/cmake support, must use absolute include paths on remote machine) and also Intellisense does not work reliably.
So I'm ready try something less restricted than Visual Studio but with somewhat similar quality and workflow, and my current best option seems to be QtCreator.
How do I achieve building for Linux from QtCreator running on Windows machine
Which approach is supported or works better (provides auto-complete and debugging conveniences) with QtCreator - cross-compile & copy binaries and launch GDB, or building the project remotely (but with option to not copy files, in case I'm building on a Samba shared folder)?
Which approach is supported or works better (provides auto-complete
and debugging conveniences) with QtCreator
Given that you say the cross toolchain is not a problem, my biggest parameter for the choice would be the size of the project and compile time. If it's a project that you can cross build in few minutes I would go for the local option.
A few notes on the prerequisite when cross compiling:
You should have a sysroot of the device your cross-compiling to which from which the linker will get all the appropriate libraries that aren't dynamically linked.
When remote debugging, I found the following a best practice. You have to have two debugging apps, gdb and gdbserver. Gdbserver is run on the embedded device while you're running gdb on the host machine. To be able to step through the code at runtime, you need to cross compile with debugging symbols. If the device has sufficient memory, you can deploy the whole binary with debugging symbols on the device.
This is a big topic :) I suggest you ask subquestions so we can form the answer step by step.
So I have a Visual Studio 2013 Update 4 solution with 2 projects inside, one target Windows 8.1, other Windows Phone 8.1 configured to build static lib.
Project is open sourced, so here is the solution for reference:
https://github.com/gideros/gideros/tree/master/winrt
What I need to do, is to make it use networking code, which uses winsockets. Since this is a library project, there was no Linker section in project properties, so I simply included
#include <WinSock2.h>
#pragma comment(lib, "Ws2_32.lib")
Both projects built without errors and when library included in Windows Phone app, it worked exactly as expected, but in Windows app networking part was not working, but also no errors or crashes.
I ran it through App Certification program and it said:
Error Found: The supported APIs test detected the following errors:
API WSACleanup in ws2_32.dll is not supported for this application type.
and lots of other references to ws2_32 library
I started searching on internet, and there were lots of posts stating that you can't use winsocket on Windows 8.1, you have to use Microsoft's winrt socket implementation etc.
But then I stumbled on this blog announcing that it is now (since VS 2013 Update 3) possible to use winsock on both Windows 8.1 and Windows Phone 8.1
http://blogs.windows.com/buildingapps/2014/10/13/winsock-and-more-open-source-for-your-windows-store-apps/
Quoting:
We’re happy to announce that starting with the release of Visual
Studio 2013 Update 3 (download) in August, the Windows App
Certification Kit (WACK) allows use of WinSock APIs in your Windows
Store apps. And since WinSock was already allowed to pass
certification on Windows Phone, this work completes the story. Now
WinSock is available universally across Windows 8.1, Windows Phone
8.1, and universal apps.
As I had VS 2013 Update 4, it should have already worked. So I checked App certification version (it was 3.3), and it stated it had update available, so I downloaded Windows SDK for Windows 8.1 from:
https://dev.windows.com/en-us/develop/app-certification-kit
And now I can't even build the project, because it says that all Ws2_32.lib parts are missing for Windows 8.1 target. (while Windows Phone 8.1 still builds and works as expected)
So is it even possible to use winsockets on Windows 8.1 apps?
And if yes, what am I missing?
Update 1:
It seems to be possible, but the problem is with my set up.
When I check the header files where my project points, then they are:
for Windows phone its
Program Files (x86)/Windows Phone Kits/8.1/Include/winsock2.h
for Windows it
Program Files (x86)/Windows Kits/8.1/Include/um/WinSock2.h
And when I check the file that is for Windows, then it has a preprocessor defined:
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
And it does not go into this if statement, thus for compiler this file is basically empty
I even tried to uninstall Windows 8.1 SDK, which did not change anything.
Then I manually removed files from Program Files folder and installed a new one from
https://dev.windows.com/en-us/develop/app-certification-kit
still I have the same header. So where do I get latest Windows 8.1 SDK with proper winsock2 header file?
Update 2:
So I removed everything and re-installed clean VS 2013 Express Update 4 and again same result, it all builds without errors, but networking does not work on Windows 8.1 app, while it perfectly works on Windows Phone 8.1.
It is like Windows 8.1 have only empty stubs, that do nothing.
I've been asking in Windows developer forum and one of the Microsoft representatives stated that, quoting:
If you have VS 2013 Update 4 properly installed, then you will have
gotten an updated Windows 8.1 SDK. In that version of winsock2.h, only
the ASCII versions of most of the WinSock APIs are excluded from
Windows Store. You have to use UNICODE exclusively for Windows 8 Store
apps.
Unfortunately I have no idea what that means and how should I proceed. If that means defining UNICODE macro then it is already defined.
Update 3:
I've managed to debug the winsocket code and everything is running as expected there, server is listening on the port. But nothing can connect to it. It's like it is running in sandboxed mode
Update 4:
Running netstat and wireshark all seems to work correctly and see server and I can even connect to it from other computer. But I can't connect from the same computer.
And it seems that MS forbids Windows apps to communicate with desktop apps on the same machine
I have no idea why, anyone can provide any insights?
How can a Metro app in Windows 8 communicate with a backend desktop app on the same machine?
The last question is
If VS 2013 Update 4 bundles winsock2 header that builds with WACK 3.3 that does not allow winsockets, while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.
How to get WACK3.4 with correct winsock2 setup?
WinSock is supported on Windows and Windows Phone, and is allowed using WACK 3.4. It works for me using both #pragma comment(lib, "ws2_32.lib") and by adding ws2_32.lib directly to the project settings.
It looks like there is something wrong with the way you are building the project after the upgrade; can you post the errors you got after the upgrade?
So basically sockets do work, but there are couple of cases to be aware of.
There is a network isolation, which does not allow to connect to Windows Store apps from same machine (as I did in my tests and thought networking does not work).
But if you can connect from remote machine, everything works as expected.
More info on that:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd374089%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
But you still won't be able to pass WACK (which is not needed to submit to store, but still)
Problem is that VS 2013 Update 4 bundles winsock2 header that builds and works and it has WACK 3.3 software that does not allow winsockets.
While Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build and work.
As you don't need to run WACK to submit app, mostly it won't be a problem, but as I needed to check if there are any other specific libraries I use, that can be prohibited, then I had to only install single (App certification) component from Windows 8.1 SDK from here:
https://dev.windows.com/en-us/develop/downloads
And I have WACK 3.4 and proper winsockets now
Still too bad about network isolation, that basically kills the purpose of what I was porting in the first place. Making all the work basically in vain.
When running the default c++ project in Visual Studios for a Windows CE 5.0 device, I get an error complaining about missing resources. Depends says that my executable needs ayghsell.dll (the Windows Mobile shell), and CoreDll.dll. Does this mean that my executable can only be run on Windows Mobile devices, instead of any generic Windows CE installation? If that's the case, how do I create an executable targeting generic WinCE?
Depends what you mean by a generic Windows CE installation. Windows CE itself is a modularised operating system, so different devices can have different modules included. Therefore each Windows CE device can have a radically different OS installed (headless even).
Coredll is the standard "common" library that gets included in a Windows CE installation, however it can contain different components depending on the other modules in the system.
If you want to target a relatively standard version of Windows CE either target the Standard SDK set of components, or go for a Windows Mobile platform.
If you have an SDK then install and use that. If none is available then you can generate an SDK using Platform Builder and the OS project files.
To get your application to work on a non-Windows Mobile installation of Windows CE you just have to remove the code that uses the aygshell library, and not link to those libraries.