I see some devices with REX OS, but it supports Brew Zone, Applications. But BREW itself is the OS, I want to know what is the difference between REX and BREW, relationship between them. Can anyone help? Application platform is as BREW and OS is as REX in some CDMA devices.
You can understand the relationship between REX and BREW / BrewMP by way of an (admittedly not perfect) analogy with the most popular desktop environment: the Microsoft Windows XP/Vista/7 operating system and the Microsoft .NET application framework.
.NET framework is a modern set of libraries, user interface controls, and data management APIs. .NET is platform-and language-independent (it can run on Windows and Linux, and supports multiple languages - C#, C++, Visual Basic, Ruby etc.). In this environment, .NET is not your OS; Windows is the operating system on the computer, and the .NET framework runs on top of the Windows OS, using Win32 APIs internally in its implementation. .NET is higher-level and easier to program for in comparison with mostly C-based, unmanaged Win32 API.
In a similar fashion, REX OS is a real-time operating system used by Qualcomm, with BREW / BrewMP available as an application framework. Just like in Windows, you can write applications against the native REX APIs, and you can use the BREW APIs. The BREW framework is higher-level, supports multiple languages, is binary backward-compatible, has a decent simulator, and offers a UI controls package. So on a BREW phone, REX is the "real" operating system, but most if not all apps are using BREW APIs and run within the BREW framework.
This chart represents the relationship well - you can think of REX as being below the "Handset APIs".
BREW apps also have code signing, distribution, and certification processes that make it easier for application writers to support multiple devices and operators. If you would like to get your REX program on a phone, you will have to talk with the OEM directly, as it would become a part of, and would have to be installed with, the operating system.
Related
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.
For Windows there is Win32 API, what about for Mac? On Wikipedia
http://en.wikipedia.org/wiki/Cocoa_(API)
it is said that Cocoa is "one of" the API... what about the full story?
At what level? The low level API is largely but not entirely FreeBSD, and below that there is still a Mach API (some things still use Mach ports for IPC, I believe; at least, launchd supports them). At the upper level are two APIs: Cocoa and Carbon. Cocoa is the native API; Carbon is intended for programs ported from older MacOS. (Which includes parts of OSX itself; for a long time Finder was a Carbon app.)
The Windows situation isn't all that different, actually; there was for a long time a Win16 emulation API present in 32-bit Windows, and in the early days of Windows NT it had both POSIX and 16-bit OS/2 APIs.
That pretty much is the full story. Mac OS X does support other APIs, but they're either deprecated (Carbon), or intended primarily to support "foreign" software (Java, X11, POSIX). The native API is Cocoa.
Mac OS X is Unix underneath. That's the "other" API.
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.
What is the best programming language for writing MIDI-interactive musical application that would be run on MAC and on Windows?
I've written cross platform (Mac OS X and Windows) MIDI applications using C++. I used the RtMidi for MIDI I/O which was incredibly easy to get going (on every platform just it just worked out of the box). The advantage of C++ is that you can use native GUIs on each platform, but if you're not already into C++ I'd say a cross platform project is a pretty ambitious first project.
One possibility is .NET (C# or VB.Net), which runs on Windows (of course) and Mac (thanks to Mono). The downside is that .NET does not have any native support for MIDI, so you'd have to tap into two different native APIs for MIDI.
Java is another possibility, since it has a number of MIDI-supporting libraries available. Your UI is bound to look pretty terrible, though.
Python has substantial support for MIDI and runs on Mac and Win.
pygame.midi
PyPortMidi
PythonMIDI
pyrtmidi
For both mac and windows I would suggest Java. Midi is just a protocol so any language can do it. A good framework will speed things up a lot. Java has frameworks to work with Midi and other multimedia sources.
PortMidi is another popular cross-platform MIDI library. Qt is a nice cross-platform Framework, GUI and utility library.
It's an old thread, but nowdays you can use .NET. I mean official cross-platform .NET from Microsoft, not Mono. In this case I can recommend my library – DryWetMIDI. Its core part (working with MIDI files, processing MIDI data and so on) is cross-platform for any OS supported by .NET.
As for working with MIDI devices, this API supports Windows and macOS (that's what you need). Full documentation of the library availabale here: https://melanchall.github.io/drywetmidi. There you can find full API reference and help articles. For example, overview article on working with MIDI devices.
The library is distributed via NuGet package and can be installed via NuGet on both Windows and macOS.
Some of the requirements (restrictions) for such a ui framework/toolkit are:
No single vendor lock down
Ability for real time data visualization
Good initial widgets
Good dash boarding capabilities
cross platform
Good development/debug environment
No flash
It's a pity you can't/won't use Flash. Else I could really recommend Adobe AIR. It has a good editor (Flex Builder built on Eclipse), a good component framework with many out of the box components, charting components set, ability to communicate with many different protocols (and you could write your own protocol implementation), cross platform, runs in the AIR runtime and not in the browser, file IO, ...
I wouldn't pass over Flex/Air (Flash) without a closer consideration but here are a few others I have come across:
wxWidgets
GTK+
Qt
There is also a slashdot post with links to some tookits I haven't heard of. I'll add their recommendations here:
GLUI, an OpenGL-based GUI
Whisper, a Mac/Windows application framework
WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
For general information:
GUI Toolkit/Framework Page
PIGUI FAQ Page
C++ User's Journal PIGUI Page
I might suggest Mozilla XUL, but it has some drawbacks:
No really good development / debug environment (although there are tools and debuggers; they are variable)
You are locked into a vendor, but it is Mozilla.
It is very easy to use though and allows you to reuse your web Javascript skills for a rich-client app.
There's also Java of course. It satifies all your requirements AFAICS.
Plenty of custom charting controls, which are things you will struggle to find for GTK/WxWindows/$other_small_userbase_framework.
If you dont like Swing(its come a long way - Metal is dead, long live SystemDefault L&F!), there are options like SWT or even QT bindings for java(QTJambi).
For C or C++ go QT, its APIs are really nice.
For RCAs check out Eclipse RCP. For RIAs, you might be interested in OpenLaszlo. It's a rich internet platform that can compile both to Flash and DHTML.
http://www.gnustep.org/
"GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components."
Portable to: Windows, BSD-based systems, Linux-based systems, HP/UX, , Solaris, Sparc, GNUstep Solaris 10 U2 vmware appliance, OpenSolaris, others.
I recently made a pretty complete list here: http://commadot.com/ria-frameworks/
ExtJS is probably my favorite and we use that at work. I think it satisfies your list. Otherwise, there are a bunch of other possibilities on that page.