The PPC JIT works pretty well (on OS X and PPC Linux), but getting it to compile on AIX would probably take a bit of hacking to work around the various low level differences... (i don't know how weird AIX is at the POSIX level, i just know it's... somewhat idiosyncratic, to say the least... from a sysadmin point of view).
ia32 has always had the ability to mark memory non-executable at the segment level, but mucking about with segments is a pain in the arse, and something that most people were happy to leave behind in the 16bit days, so most OSes just use a single 32bit segment as a flat address space, and it's never got much use. It's by doing tricks with segments that OpenBSD's W^X and the various things in some RedHat kernels, etc, work, but they're not nearly as straightforward as having proper support for per-page control over executability.
XP's theming abilities have absolutely nothing in common with alternative shells. the themes merely change the way the windows/widgets look, but the interface is still exactly the same, with the same taskbar/start menu/desktop shell. litestep/geoshell/etc replace the taskbar/start menu/desktop, but do nothing to the windows/widgets.
No, it is more akin to the shift from the old DOS/9x codebase to the NT kernel. It's just that MS managed the transition better, since they provided an API (win32) that ran on both, and didn't confuse the situation with another API that ran only on the NT kernel.
Apple could have had a similar transition using Carbon, which runs on both OS9 and OSX, if they'd planned ahead better, rather than fscking about with the whole Copland ("hm, no, maybe not, it's crap and we aren't getting anywhere..."), Rhapsody ("yes! a decent OS that actually WORKS! What do you mean people don't want to rewrite everything from scratch to target a new API that has precisely nothing in common with the old one?"), OSX ("OK, we'll clean up the old Mac Toolbox API, and port it to OSX, so you can target both the old OSes and the new one at the same time. We'll just not actually finalize the spec for the new api until after we've released the first version of the new OS!!").
If they'd come up with Carbon when they first bought Next, they could have rolled carbonlib out with OS9 (or maybe even 8.5 maybe? i'm not sure of the timeline), and got most apps targeting it relatively easily. Then when OSX was released, they could have had Photoshop et al running natively right from the start.
Slashdot Mirror
[Disagree]_________[Cancel][Agree]
It already does. (and has done for quite a while now... the generics support was considered feature-complete at version 0.31...)
The PPC JIT works pretty well (on OS X and PPC Linux), but getting it to compile on AIX would probably take a bit of hacking to work around the various low level differences... (i don't know how weird AIX is at the POSIX level, i just know it's... somewhat idiosyncratic, to say the least... from a sysadmin point of view).
And to add the .NET part back in, IronPython (at least, once it actually becomes available...)
ia32 has always had the ability to mark memory non-executable at the segment level, but mucking about with segments is a pain in the arse, and something that most people were happy to leave behind in the 16bit days, so most OSes just use a single 32bit segment as a flat address space, and it's never got much use. It's by doing tricks with segments that OpenBSD's W^X and the various things in some RedHat kernels, etc, work, but they're not nearly as straightforward as having proper support for per-page control over executability.
You mean like linux embraced and extended the POISX standard?
that bug's fixed in 2k sp3/XP sp1
runas /?
(grr. fucking 20-second delay...)
XP's theming abilities have absolutely nothing in common with alternative shells. the themes merely change the way the windows/widgets look, but the interface is still exactly the same, with the same taskbar/start menu/desktop shell. litestep/geoshell/etc replace the taskbar/start menu/desktop, but do nothing to the windows/widgets.
- Controlled entirely by Sun.
- You need to apply to them for a license before you can implement it (well, before you can call your implementation java, anyway).
- Any changes to the language must be endorsed and approved by Sun.
- If you deviate from the spec even slightly, you're likely to end up on the wrong end of a lawsuit courtesy of Sun (judging from prior behaviour).
Compare this to C#/the CLR:- Has been submitted to the ECMA for ratification.
- May be freely implemented by anyone, by following the freely available specification.
- Changes to the spec will go through the ECMA.
Which seems more "open" to you?No, it is more akin to the shift from the old DOS/9x codebase to the NT kernel. It's just that MS managed the transition better, since they provided an API (win32) that ran on both, and didn't confuse the situation with another API that ran only on the NT kernel. Apple could have had a similar transition using Carbon, which runs on both OS9 and OSX, if they'd planned ahead better, rather than fscking about with the whole Copland ("hm, no, maybe not, it's crap and we aren't getting anywhere..."), Rhapsody ("yes! a decent OS that actually WORKS! What do you mean people don't want to rewrite everything from scratch to target a new API that has precisely nothing in common with the old one?"), OSX ("OK, we'll clean up the old Mac Toolbox API, and port it to OSX, so you can target both the old OSes and the new one at the same time. We'll just not actually finalize the spec for the new api until after we've released the first version of the new OS!!"). If they'd come up with Carbon when they first bought Next, they could have rolled carbonlib out with OS9 (or maybe even 8.5 maybe? i'm not sure of the timeline), and got most apps targeting it relatively easily. Then when OSX was released, they could have had Photoshop et al running natively right from the start.