On Wed, Aug 21, 2013 at 6:40 PM, William ML Leslie < [email protected]> wrote:
> I really can't figure out what you're trying to say here, can you > elaborate on the problem? > I'm talking about systems runtimes and libraries for end-user operating systems. Userland backward-compatible shared-libraries are heavily used, both because userland is often the fastest place for shared functionality to live, and also because binary module updates can fix system library bugs and isolate applications from systems issues. Examples of such userland shared system core code includes: Windows C (win32, GDI, Winforms, COM, ATL), CLR (Windows.Forms, WPF) Win8/WP CX (WinRT), CLR (WinRT) MacOS C (posix/bsd, carbon) Objective-C (Cocoa/Appkit) Android C (NDK) Dalvik (java sdk) C++, Ocaml, Haskell, D, Google Go, and others are not missing from this list because nobody has gotten around to building a system based on them, but because they are whole-program embedded systems compilers. The best they can do is import some of the above system-libraries, but they are not used to *build* something like them, because they (either explicitly or practically) do not support binary upgradable shared libraries. (ask Taligent/Pink/BeOS!) My point was that contrary to comments made that JVM and CLR have not made headway in this type of systems programming, I'm pointing out that they are the some of the *only* runtimes that have made headway. From the list above, you can see it's basically C, Objective-C, CLR, and Dalvik/JVM -- with Microsoft's recent CX compiler<http://en.wikipedia.org/wiki/C%2B%2B/CX> the latest entry.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
