I have a vague recollection of reading somewhere in Microsoft's documentation (it might have been to do with BLE APIs), that some APIs are only available to apps downloaded from the Windows Store. I just searched again and can't find anything. Did I misremember or is this the case for some APIs?
I'm not aware of any APIs that aren't available in a side-loaded application, but APIs from the Windows.ApplicationModel.Store for example may not function in a meaningful way (like ListingInformation wouldn't be useful).
Related
Microsoft and Apple have recently introduced an API for synchronizing cloud storage files to the local file system: Cloud Provider API (also known as Cloud Filter API) for Windows and File Provider API for Apple and iOS. For example, the Microsoft OneDrive client is now built on top of this new API.
Is there a similar API for major Linux flavors?
AFAIK, I don't think there are any APIs like that to achieve this in Linux. However, we can make use libfuse (https://github.com/libfuse/libfuse) to achieve the same. Earlier, cloud storage vendors like Dropbox, Box, Google Drive, NextCloud, and Filr made use of the same library prior to the advent of File Provider API and Cloud Provider API (which are very recent technologies, but standardized for macOS and Windows).
From my limited knowledge, I think libfuse makes use of a kernel extension to create a virtual filesystem where you can implement filesystem calls. There are many abstraction layers written on top of libfuse for different programming languages like rust, objc/c++, python etc...
For Eg.
fuse-python (https://pypi.org/project/fuse-python)
python-fuse (https://github.com/libfuse/python-fuse)
macfuse (https://github.com/osxfuse/osxfuse)
Apple stopped loading of 3rd party kernel extensions from macOS 11, so their alternative offering to fuse-based cloud storage clients is File Provider API.
In Windows, prior to the Cloud Storage API, the same was achieved using Minifilter drivers (https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/filter-manager-concepts)
These alternative APIs are offered by Apple and Microsoft for their respective platforms, mainly because of securiry reasons. A small flaw is kernel or a driver code would be fatal for the entire OS.
So, I think libfuse would be the best approach for Linux-based OS'es for now, until someone comes up with a more feasible solution.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
I know the midiXxx API, but I saw it is currently listed under 'legacy' in msdn.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743619(v=vs.85).aspx
Is there some other API i should use to target the newer Windows versions?
Will the old API still work on Windows 7 and 8?
Thanx,
Marc
Last Friday Microsoft released a preview Windows Runtime API for MIDI. Check out the //build/ session here:
http://channel9.msdn.com/Events/Build/2014/3-548
MSDN: http://msdn.microsoft.com/en-us/library/windows/apps/dn643522.aspx
Although a preview, apps can go live and be deployed to the Windows Store. Please let us know what you like or don't like. Happy app building!
For dektop applications (non metro) you can still use the legacy API safely.
Sadly for WinRT/Metro, there is no midi support at all (see this discussion on msdn).
Hope they will change that.
Catflier is correct that there is no direct support (at the API level) for MIDI in WinRT. However, if you are wanting to have MIDI-like capabilities in your app, there are workarounds. A protocol growing in popularity is the network-based OSC (Open Sound Control). Since it is network-based, you can use that.
For example, one can use external hardware like The Missing Link which translates from MIDI to OSC. You hook up your MIDI device to The Missing Link, which then translates to OSC messages that are sent to the computer. Your app can then receive OSC messages and talk to the MIDI device. I don't have any code to show here, but I've seen demos of this working in-action.
You can see OSC in use on iOS as well with popular apps like TouchOSC.
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.
I need to scan Wifi access point on Windows Mobile and connect the one of scanned results.
Currently I am using C# language, Windows Mobile 6.5 device, also to scan I am using the below code.
[DllImport(wlanapi.dll", SetLastError=true)]
I am using wlanapi.dll, but it seems that not possible to use on Mobile.
Does anyone know about the belows.
Could I use the dll in Windows Mobile 6.5 to scan and connect?
If the 1 is not possible, please let me know the different methods..
Please give me the clues.
wlanapi.dll doesn't exist in WinMo/WinCE. You have to use an API that is supported.
Most WinMo WiFi drivers (though probably not all) support the Wireless Zero Config (WZC) set of APIs. The native versions of these APIs, like WZCQueryInterface, are outlined in MSDN.
Microsoft does not provide any managed interface for these APIs, in fact the native documentation for them is pretty bad too. The definitive "example" of it's use is in the NETUI component source of Platform Builder. Gettign the eval version just for the source is very worthwhile if you plan to do much WinCE/WinMo development.
From a managed perspective I wrote an MSDN article back in '06 that talks about using the SDF for getting network info. The SDF has been reworked a lot since then, especially in the WZC area, but it's still pretty similar.
I did an updated blog post in '07 about custom-drawn ListBoxes, and while that's not what you're after, the data being displayed is wireless network info, which is in line with what you're after.