I was looking through Microsoft's port of OpenSSL on GitHub. One commit caught my eye, and it was Adding Win10 Universal Platform support. In the commit, a partition called WINAPI_FAMILY_ONECORE_APP showed up. However, I'm not finding much about it when searching. There are two hits in English and 22 hits in Chinese (see below).
Following What’s new in Visual Studio Tools for Windows 10 Preview provides some quasi-bullet points with no explanations:
new API partition WINAPI_FAMILY_ONECORE_APP
ARM 64
Universal CRT
...
I have two questions:
What is WINAPI_FAMILY_ONECORE_APP, and how is it intended to be used?
Can I use WINAPI_FAMILY_ONECORE_APP to detect Aarch64/ARM64 on Windows 10 gadgets?
Here's Microsoft's use of it in OpenSSL (snipped from ssl/dtls1.h; the C++ comment was moved above the define for readability):
// winsock.h not present in WindowsPhone/WindowsStore, defining the expected struct here
#if defined(WINAPI_FAMILY) && ( WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP || WINAPI_FAMILY==WINAPI_FAMILY_PC_APP || WINAPI_FAMILY==WINAPI_FAMILY_ONECORE_APP)
struct next_timeout {
long tv_sec;
long tv_usec;
} next_timeout;
I think this is API which are available to all windows platforms (mobile, PC, xbox, hololens, IoT).
Windows OneCore
Windows OneCore is a platform for any device—phone, tablet, desktop,
or IoT. Windows 10 provides a set of API and DDI interfaces that are
common to multiple editions of Windows 10. This set of interfaces is
called OneCore. With OneCore, you can also be assured that drivers and
apps that are created using OneCore interfaces will run on multiple
devices.
Related
I accessed the Chrome BLE API page (5/7/2016). there seem to be conflicting information messages (see image below). Does this work on Chrome OS only, or OS X and Windows also?
EDIT/UPDATE:
I tried the demo application (demo BLE API) on Windows 10. It was able to see paired devices, but not unpaired devices. I got an error message: Battery device not supported on this platform. I'm not sure if this is because of the test vector I used (LightBlue), or another issue.
System:
Windows 10 64 bit
Surface Pro 3
The chrome.bluetoothLowEnergy API works only for paired devices on Windows as it still uses (at that time) Windows 8 APIs to retrieve paired devices only: https://chromium.googlesource.com/chromium/src/+/08c9d69b0c0d625d2ce38e3d8402f36e1226f0fc/device/bluetooth/bluetooth_low_energy_win.h#117
For info, the Web Bluetooth team plans to support Windows 10 as much as feasible: https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md#chrome
Reading through your given documentation wherein you referenced the use of navigator.bluetooth, Interact with BLE devices on the Web also states that:
Web Bluetooth API is at the time of writing partially implemented in Chrome OS and Chrome Dev for Android behind an experimental flag.
Hence, you got undefined as a return value.
Functionalities were provided by Bluetooth Low Energy (BLE) through key/value pairs provided by the Generic Attribute Profile (GATT).
I Want to know if Windows CE 7.0 has same API and functionality with normal Windows system programming.
For example, i have to deal with serial(RS-232), TCP/IP, select() and so on in Windows CE 7.0.
Can i use all of API same as normal Windows?
Or there are some Difference between them ?
The API are similar, but you should expect some differences.
For example serial port drivers may not support asynchronous read/writes. This is supported in the OS (since ver 7.0), but I have seen no drivers actually using it.
Also socket API is similar but, as you know, evil hides in details.
As a general rule you can't take for granted that software running on Windows desktop (or "normal" if you prefer :)) will just need a rebuild to run on CE.
It will need at least a rebuild (and sometimes this may be clumsy if you are using different releases of Visual Studio).
We currently have a custom board with a microcontroller on it that speaks to a PC/104 windows CE 5.0 board through a dual port ram. Currently we use MmMapIoSpace to map the dual port ram in windows CE so we can read and write directly to it. We are looking to join the modern era of windows CE 6.0 or even windows XP embedded. A big concern of ours is that according to Microsoft's documentation MmMapIoSpace in windows CE 6.0 and in Windows XP Embedded are now driver level functions not accessible to in a user space program which is how we have been using it.
Before we go out and buy a lot of hardware and possibly a copy of platform builder we have been trying to figure out if it will actually be a problem and if so what we can do about it. None of us have experience writing windows drivers so that seems like a large undertaking however we would literally be writing a driver just to handle this one function.
Is it simple to port MmMapIoSpace from Windows CE 5.0 to Windows CE 6.0 or Windows XP Embedded. (links to Microsoft documentation).
Thanks!
MmMapIoSpace really should only be used by a driver in the first place, so earlier CE versions were simply a bit promiscuous in letting you use it from an app. I'd create a simple stream interface driver that interfaces with the RAM using MmMapIoSpace, and then call that driver from you app either using ReadFile or DeviceIoControl.
Stream interface drivers in Windows CE are very simple and straightforward. It's just a DLL with some specific entry points defined, and then registry entries to tell device.exe to load it. MSDN has lots of examples, but if you want even easier, there's a wizard on Codeplex that can generate the files for you too.
Is it possible to manually edit the driver to make it function on windows XP?
I guess there are many differences, but it must be possible for simple drivers, kind of porting the locations / buses they use?
Do you mean without re-compilation? If so its not recommended.
If you are willing to compile then use appropriate WDK and select appropriate build environment and try to build. You may have to change the code depending upon any APIs changed/availability.
Also note that drivers are compiled per OS i.e. there are different build environments for WinXP, Windows 2003, Windows Vista, Windows 7 etc.
Is there any solution to run a Windows XP executable on a Windows CE or Windows Mobile Device? Actually I think it is almost impossible or at least it would be very tricky however, I have a client says that the vendor of his Windows based application declared that the app runs on Windows XP as well as Windows CE.
Is this possible? Is there any way to convert Windows XP executable (native machine code) to Windows CE (running on x86 CPU) executable?
Native code won't work out the box because the Win32 and WinCE API's are similar, but quite different at the same time. Even when they overlap, WinCE expects the API to live in coredll.dll instead of system32.dll and friends.
If it's a simple app, and you know exactly what APIs are being called, you could write a wrapper coredll.dll that exposes the WinCE style APIs. There will be lots of unicode conversion involved!
If it's a .net compact framework application it will run if the app only references the parts of the API that are common to compact framework and the full .net framework.
It's possible to develop a cross-platform .net app that shares the bulk of the code, and has separate pinvoke layers for the CE and XP APIs respectively (if you are using them).
Converting the final executable may be well-nigh impossible in some cases, but if the vendor deliberately designed it to work on both systems, then it probably does (the task would be much easier for someone who possessed the source code).