I have a Windows program which a handful of Mac users are asking for. I don't have the skill or incentive to make a dedicated Mac version. Is it allowable to redistribute my software in a Wine wrapper when it relies on the SAPI engine?
It depends. If you're using SAPI components that come as part of a separately redistributable package (e.g., Microsoft Speech Runtime 11), those components have a specific license that allows for 3rd party redistribution. If you're using SAPI components that are distributed as part of the operating system (e.g., SAPI 5.4 & the desktop SR and TTS engines), then no, you're not allowed to redistribute them.
Related
I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
Is Universal Windows Platform the replacement of WinRT of Windows 8 and Windows Phone apps?
I mean, there was a WinRT platform to develop metro apps exclusively for Windows 8. Now, that is replaced by UWP, isn't it?
That is correct, UWP is the new platform for ALL Windows devices going forward (Win 10+). However WinRT is not replaced by UWP but is instead an extension on top of it, making UWP a much broader set of APIs that can be used across even more devices. As Microsoft themselves state:
With this evolution, apps that target the UWP can call not only the WinRT APIs that are common to all devices, but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.
The UWP platform supports the "Universal Device Family" class of APIs which is then supported on ALL windows platforms (Xbox, Phone, Desktop etc). There are some extension families that you can use that will limit the apps reach, such as a "Mobile Device Family".
These specific device family APIs can however be checked for and used at runtime gracefully. For example you could show your own position using GPS on a phone, but not enable that functionality on a Xbox.
I hope this answer helps you, if you have any more questions about this I recommend reading this article about the UWP platform:
Source: https://msdn.microsoft.com/library/windows/apps/dn894631.aspx
Have a wonderful day!
This is a bit confusing because in Windows 8.x, "Windows Runtime" was actually used to refer to a few different things:
A new pattern (and supporting code/OS components) for defining and consuming Windows APIs, meant to largely supersede "Win32" (i.e., flat C-style) and classic COM for new APIs in most scenarios. This was/is really about language interop: allowing the Windows team (and potentially others) to create components in C++ that expose APIs that don't depend on GC or a runtime like the CLR, but still feel relatively natural to use from C# or JavaScript without needing manually written wrappers.
The set of Windows APIs that follow the above pattern.
A new platform/environment for building and running a new type of Windows app, which are meant to have some of the characteristics of mobile and web apps in terms of causing fewer potential problems with system security, reliability, performance, battery life, etc. This is what evolved into UWP with Windows 10.
In the Windows 8 days, these apps were called "Metro style apps" during most of 8.0's public preview period, and officially dubbed "Windows Store apps" just before RTM. The platform/environment for these apps ... officially didn't really have a name (other than "platform for Metro style apps"). Unofficially, people (including at Microsoft) sometimes referred to it as "Metro" (a whole can of worms in itself) or ... "WinRT".
So what's the relationship between WinRT "proper" (definitions 1 and 2), and unofficial WinRT definition (3) aka UWP aka the formerly-nameless "platform for Metro style apps"? Well, since WinRT and the new app platform were both introduced in Windows 8, most of the WinRT APIs at that time were specific to the new platform. The app platform (and Store policy) at the time was also much more restrictive about which legacy Win32 APIs were allowed for use in apps - for the most part this was less about any technical limitation and more about the team hoping to use the new apps as an excuse to clean up the bloated Win32 API surface. But technically, WinRT is meant to be the common pattern for new Windows APIs in general, whether used in UWAs or not, and "UWA vs. classic app" and "WinRT vs. Win32" are mostly independent; over time, they've gradually enabled more WinRT APIs for use outside UWAs and also relaxed their policies on using a lot of legacy Win32 APIs in apps (and also continued to introduce new flat C-style APIs for certain use cases).
So to summarize, it's not technically accurate to say that "UWP replaced WinRT", though understandable since this stuff is pretty confusing. UWP replaced the nameless app platform (3); essentially it's just an updated version that's been ported to other device types and integrated with the classic desktop UI. WinRT, in its proper definition (1), continues to be the basis for new Windows APIs for use in UWAs and even outside them.
Windows Universal Platform is the development platform going forward for devices running Windows. Previously, development was separate for Desktops and Tablets vs Phones. With UWP you are now able to target any device running Windows 10, could be phone, desktop, tablet, xbox. The beauty is that you can now use one Binary for all of these platforms and has brought us much closer to a truly to a universal Windows app.
So, to answer your question, yes, UWP is the platform going forward for any device which runs Windows 10
Let's say that I want to add TTS support to my project, and that I hate the voice of Microsoft Sam, Microsoft Mike and Microsoft Mary.
Would it be possible for me to include a new TTS voice that I bought into my software, so that the TTS support could be limited to the voices I included, instead of the software picking voices from the computer it runs on?
If so, what engine / sdk should I use for this?
I have been searching for answers on google, but I can only find ways to use SAPI with voices from the computer.
SAPI Voices that are paid are usually licensed to the owner of the computer. You might be able to include free TTS voices from the Festival Engine.
I wanted to start with the smartcard programming soon. Please help me the things required for starting the learning using javacard. Which IDE (If any IDE Supports), Software and Hardware related? Like Mobile phone simulator is there any smartcard simulator or else if I have to buy a smartcard specify those cards where and how I can get?
A general answer regarding smartcard programming is that you should be ready to navigate a confusing list of tools and technologies. Typically smartcard developers begin with a specific hardware platform in mind: more specific than simply javacard.
Since you've specifically mentioned javacard, we can focus on a few starting points.
Javacard SDK
You might begin with the javacard dev kit. I haven't used the most recent - I'm still using 2.0.2. This dev kit is very command-line oriented, so expect to be doing most of your work outside an IDE. However, the documentation is pretty helpful and should get you up to speed pretty quickly. At any rate, it's a good place to start, since it's official.
EclipseJCDE also looks interesting, but I haven't used it. I seem to recall another project aiming to build javacard Eclipse tools, but I may just be thinking of EclipseJCDE.
IBM Tools
At one time IBM published and maintained a set of JCOP tools that integrated with the Eclipse IDE. The great thing about this is that they would send you a package containing some dev tools and a couple of JCOP cards. The annoying thing is that an activation code was required. Have a look here. The download link is still good, good luck with the email address listed there. Also note that these tools require an older build of Eclipse. The build/debug support is very good, including a built-in javacard simulator.
Global Platform
If you plan on doing javacard programming, you should also get to know Global Platform. It's a smartcard standard, and in the context of javacard, you'll need to know about the GP spec when you need to load and manage javacard applets. This is required for working with JCOP cards. For the latest GP spec search for GlobalPlatform Card Specifications. You'll need to be very familiar with basic smartcard concepts, e.g. APDUs.
Hardware
Hardware choices are too varied for me to make useful recommendations, beyond the JCOP stuff above. As I mentioned, if you can use the IBM kit then you'll get a good JCOP/javacard simulator with the Eclipse tools. I'm sure there are other card simulators available.
etc.
Beyond that there is a long list of other technical specifications employed by smartcard programmers, and unfortunately many of them aren't freely available (ISO docs). If you'll be doing GSM programming, I think you can get to all of the GSM specs, search for ETSI GSM specifications. GSM 11.11 is particularly useful for learning more about APDU command/response, without access to ISO specs, e.g. ISO 7816-4.
Share two new Free tools that I am using to learn javacard here.Hope to help others get started with javacard easily.
JCIDE: It is an Integrated Development Environment designed specifically for the Java Card programming language.
PyAPDUTool: It is a handy tool which can communicate with the card via the reader connected to PC. It is a PC/SC compliant application.
we are starting a new desktop project and we are evaluating adobe air as our development platform. this is because most our team are flex developers and we want to take advantage of that. but we have several question in order to decide whether or not to use air as a development platform.
How recomended is to use a bridge to
communicate with peripherals through
serial and paralell ports.How can i
communicate air application with my
system database.
There is a well known framework for
object persistence, like hibernate
??. if not, what is the best approach.?
Which are the best approach for our
applications distribution, how can we
deal with product key, product
licenses, etc. What advantage do we
have using AIR MarketPlace ?
Any help you can provide me, to point me in right direction, i will appreciates
Cheers,
system communication via NativeProcesses (since Air 2.0)
Air supports SQLite; from Air you can communicate via RPC or socktes with (for example) a JavaServer with Hibernate
Air App Licensing with Sharify
Damian