-
Notifications
You must be signed in to change notification settings - Fork 23
SupportedOperatingSystem
In a general manner we support 3 Operating Systems
- Windows
- Mac OS X
- Linux
For Intel CPU in either 32-bit or 64-bit.
That's what we call supported in the large.
In more details it is mainly
- Windows 8.1
on Intel 32-bit and 64-bit - Mac OS X 10.10 Yosemite
on Intel 32-bit and 64-bit - Linux Ubuntu 15.10 Wily Werewolf
on Intel 32-bit and 64-bit
Those are the OS where we compile and test redtamarin, I consider them most current and most used.
But there is also the original Tamarin build which Redtamarin reuse. That build was made in a such a way that many more targets can be supported: Mac OS X on PPC, Linux with MIPS or SH4, Solaris with SPARC, etc.
This is what we call Can build but we do not build them by default or write code for them by default.
Windows | version | can build | supported | CPU | Arch |
---|---|---|---|---|---|
95 | 4.0 | no | no | intel | 32-bit |
98 | 4.1 | no | no | intel | 32-bit |
ME | 4.9 | no | no | intel | 32-bit |
2000 | NT 5.0 | yes? | no | intel | 32-bit |
XP | NT 5.1 | yes? | no | intel | 32-bit |
XP | NT 5.1 | yes? | no | intel | 64-bit |
Server 2003 | NT 5.2 | yes? | no | intel | 32-bit |
Server 2003 | NT 5.2 | yes? | no | intel | 64-bit |
Vista | NT 6.0 | yes? | no | intel | 32-bit |
Vista | NT 6.0 | yes? | no | intel | 64-bit |
Server 2008 | NT 6.0 | yes? | no | intel | 32-bit |
Server 2008 | NT 6.0 | yes? | no | intel | 64-bit |
Home Server | NT 6.0 | yes? | no | intel | 32-bit |
Home Server | NT 6.0 | yes? | no | intel | 64-bit |
7 | NT 6.1 | yes? | yes | intel | 32-bit |
7 | NT 6.1 | yes? | yes | intel | 64-bit |
Server 2008 R2 | NT 6.1 | yes? | yes | intel | 32-bit |
Server 2008 R2 | NT 6.1 | yes? | yes | intel | 64-bit |
Home Server 2011 | NT 6.1 | yes? | yes | intel | 32-bit |
Home Server 2011 | NT 6.1 | yes? | yes | intel | 64-bit |
8 | NT 6.2 | yes? | yes | intel | 32-bit |
8 | NT 6.2 | yes? | yes | intel | 64-bit |
RT | NT 6.2 | no | no | ARM | 32-bit |
Server 2012 | NT 6.2 | yes? | yes | intel | 32-bit |
Server 2012 | NT 6.2 | yes? | yes | intel | 64-bit |
8.1 | NT 6.3 | yes | yes | intel | 32-bit |
8.1 | NT 6.3 | yes | yes | intel | 64-bit |
RT 8.1 | NT 6.3 | no | no | ARM | 32-bit |
10 | NT 10 | yes? | yes | intel | 32-bit |
10 | NT 10 | yes? | yes | intel | 64-bit |
see:
Mac OS X | codename | can build | supported | CPU | Arch |
---|---|---|---|---|---|
10.0 | Cheetah | no | no | PPC | 32-bit |
10.1 | Puma | no | no | PPC | 32-bit |
10.2 | Jaguar | no | no | PPC | 32-bit |
10.3 | Panther | no | no | PPC | 32-bit |
10.4 | Tiger | no | no | PPC | 32-bit |
10.4 | Tiger | no | no | PPC | 64-bit |
10.5 | Leopard | no | no | PPC | 32-bit |
10.5 | Leopard | no | no | PPC | 64-bit |
10.6 | Snow Leopard | no | no | Intel | 32-bit |
10.6 | Snow Leopard | no | no | Intel | 64-bit |
10.7 | Lion | no | no | Intel | 32-bit |
10.7 | Lion | no | no | Intel | 64-bit |
10.8 | Mountain Lion | yes | no | Intel | 32-bit |
10.8 | Mountain Lion | yes | no | Intel | 64-bit |
10.9 | Mavericks | yes | yes | Intel | 32-bit |
10.9 | Mavericks | yes | yes | Intel | 64-bit |
10.10 | Yosemite | yes | yes | Intel | 32-bit |
10.10 | Yosemite | yes | yes | Intel | 64-bit |
10.11 | El Capitan | yes | yes | Intel | 32-bit |
10.11 | El Capitan | yes | yes | Intel | 64-bit |
10.12 | Sierra | yes | yes | Intel | 32-bit |
10.12 | Sierra | yes | yes | Intel | 64-bit |
10.13 | High Sierra | no? | yes | Intel | 64-bit |
see:
Linux | version | codename | can build | supported | CPU | Arch |
---|---|---|---|---|---|---|
Debian | 5.0 | Lenny | yes? | no | Intel | 32-bit |
Debian | 6.0 | Squeeze | yes? | no | Intel | 32-bit |
Debian | 7.0 | Wheezy | yes? | no* | Intel | 32-bit |
Debian | 7.0 | Wheezy | yes? | no* | Intel | 64-bit |
Debian | 8.0 | Jessie | yes? | yes | Intel | 32-bit |
Debian | 8.0 | Jessie | yes? | yes | Intel | 64-bit |
Debian | 9.0 | Stretch | yes? | yes | Intel | 32-bit |
Debian | 9.0 | Stretch | yes? | yes | Intel | 64-bit |
Debian | 10.0 | Buster | yes? | yes | Intel | 32-bit / 64-bit |
Debian | 11.0 | Bullseye | yes? | yes | Intel | 32-bit / 64-bit |
Debian | 12.0 | Bookworm | yes? | yes | Intel | 32-bit / 64-bit |
Ubuntu | 8.04 LTS | Hardy Heron | yes? | no | Intel | 32-bit |
Ubuntu | 8.10 | Intrepid Ibex | yes? | no | Intel | 32-bit |
Ubuntu | 9.04 | Jaunty Jackalope | yes? | no | Intel | 32-bit |
Ubuntu | 9.10 | Karmic Koala | yes? | no | Intel | 32-bit |
Ubuntu | 10.04 LTS | Lucid Lynx | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 10.10 | Maverick Meerkat | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 11.04 | Natty Narwhal | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 11.10 | Oneiric Ocelot | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 12.04 LTS | Precise Pangolin | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 12.10 | Quantal Quetzal | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 13.04 | Raring Ringtail | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 13.10 | Saucy Salamander | yes? | no | Intel | 32-bit / 64-bit |
Ubuntu | 14.04 LTS | Trusty Tahr | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 14.04 LTS | Trusty Tahr | yes | yes | Intel | 64-bit |
Ubuntu | 14.10 | Utopic Unicorn | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 15.04 | Vivid Vervet | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 15.10 | Wily Werewolf | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 16.04 LTS | Xenial Xerus | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 16.10 | Yakkety Yak | yes | yes | Intel | 32-bit / 64-bit |
Ubuntu | 17.04 LTS | Zesty Zapus | yes? | yes | Intel | 32-bit / 64-bit |
Ubuntu | 17.10 | Artful Aardvark | yes? | yes | Intel | 32-bit / 64-bit |
Ubuntu | 18.04 LTS | Bionic Beaver | yes? | yes | Intel | 32-bit / 64-bit |
RedHat | x.y.z | ??? | yes? | yes? | Intel | 32-bit / 64-bit |
CentOS | x.y.z | ??? | yes? | yes? | Intel | 32-bit / 64-bit |
Gentoo | x.y.z | ??? | ??? | no | x | x |
Slackware | x.y.z | ??? | ??? | no | x | x |
SuSE | x.y.z | ??? | ??? | no | x | x |
Arch | x.y.z | ??? | ??? | no | x | x |
see:
Here a couple of examples of what kind of work would be needed to support more OS.
This would not be too hard as the support was already there in the Tamarin build,
we would mainly need to compile with the flag -mmacosx-version-min=10.5
and it should work.
But the more Redtamarin will grow and use native API the more such "old" build should be maintained or at least tested for the odd thing that would need a special treatment to be able to compile.
So it is not a "one shot", even if it take a week or so (maybe) to check everything is in place and working it would need a dedicated developer to maintain this particular platform on a regular basis.
Considering the amount of users using it (very low) I can't and won't do it, but if you know someone who want to commit to such development yeah sure no problem.
Note:
In some case it is possible to build it even if marked "can build? no"
but this would require patching the code.
Recently I needed to compile for Mac OS X 10.7.5 Lion
and even by using --mac-sdk=107
I encountered
some errors related to dirfd
and mach_task_basic_info
.
Nothing impossible to solve but still it creates more complex
branching in the code than necessary, for ex not only
you need to test for AVMSYSTEM_MAC
but then you need to test
also for the SDK version number with __MAC_OS_X_VERSION_MIN_REQUIRED < __MAC_10_8
etc.
and we definitively do not want that in the main source code.
This one would be much more difficult, for example a SPARC T7-1 Server starts around $40,000 (if you want to support what is current) or you could have an old sparc server found on eBay for a couple hundred dollars, my point is you would need the hardware to test this particular OS and CPU.
And then you would need to write and implement a lot of code to provide support for Solaris,
look into src/platform/unix/ and search for SOLARIS
, AVMPLUS_SPARC
, AV_SPARC_V8PLUS
, AV_SPARC_VIS
, AV_SPARC_VIS2
, etc.
Just search for "solaris" in the source code, yep that a lot of code to patch, update, and maintain.
On top of that you would have to probably re-implement or at least re-test all the Redtamarin native implementations like the POSIX library, this is weeks if not months of hard work.
So yeah that would be a lot of work and you would need to know Solaris pretty well, which explains exactly why I don't support it.
The only way I could see such platform supported would be for someone to sponsor such development, not gonna be me and pretty sure never gonna happen.
This one is also a particular case, in the sources you can see some references to RT with src/platform/winrt
, AVMSYSTEM_WINDOWSSTOREAPP
but clearly a lot of things are not implemented.
Again, this would require a dedicated hardware and a lot of work to support.
Well this one would require some work but it would be quite feasible eg. "not that hard".
First, because of the way that the original tamarin/avmplus project was setup by the Adobe Team, we can compile for multiple CPU architecture while targeting the same operating system, and in this case for Linux we would need to rely on the availability of glibc for ARM.
All the "core code" have already been implemented in tamarin/avmplus, that means things like AvmCore
, NanoJIT
, ShellCore
, the AS3 builtins etc. should be working "by default" for the ARM architecture.
And because our implementations of native classes like C.stdlib
, C.unistd
, etc. rely mostly on glibc
and that one is available for ARM then it should also work "by default" or almost, at worst a very few patching and other ifdef in the AVMPI/VMPI etc. should happen.
Second, the original tamarin/avmplus project when implemented for ARM has been tested on Beagle Board and from the configure.py
we can see that ARMv5, ARMv6 and ARMv7 seems to be supported.
So to test on real hardware the investment would be quite cheap with a BeagleBone Black (about $100), and then on this hardware we could install Ubuntu's ARM port for BeagleBoard, BeagleBoard-xM and BeagleBone.
From that point we would need either to cross-compile from a Linux Desktop/Server with an Intel CPU to target an ARM CPU, or we could even install our tools/sources/etc. and compile from the beagle board itself.
To test on virtual hardware (in a VM) we could also use something like that Beagleboard Emulator in Ubuntu with Qemu and other way to emulate things like a Raspberry Pi and even Android.
So yeah this one is possible and very interesting (for IoT projects for ex), I'm just lacking time to do it myself right away.
Let's be pragmatic, for now there is one guy (me) developing Redtamarin and already supporting Windows, Mac OS X and Linux is already hard and time consuming, I personally can not support more "as is".
For anything as an "easy fix", sure I will look into it, already happened in the past with CentOS for example, I made a little mistake in a native class, someone complained it was not working with CentOS x.y version, so I installed CentOS under a VM, fixed the thing and republished an updated version.
This took about 2h, it's not that hard to do but still time consuming.
My general approach will be if you really really need/want a particular OS supported you will need to find a platform "champion" for this OS.
Also this OS should not be too old, for example: even if someone was willing to put a considerable amount of time to support Mac OS X 10.4, I would not be too hot to spread all the necessary patches to compile for this very old version.
It could be you or someone else, but someone willing to check out the Redtamarin sources and compile it under that particular platform, simply put: someone ready to invest time to maintain this particular combination of OS and CPU.
Maybe later, if/when Redtamarin become useful and popular some people or organisation will be able to sponsor the support of some particular platform, but don't hold your breath it could take some time.