Write once, run everywhere” is a familiar promise. How does this avoid the problems of Java?
UDI is a specification that builds on other specifications. For example, it mandates the use of freestanding ISO C. Such compilers (and programmers) are plentiful. A UDI driver doesn’t exist as bytecode or within a virtual machine. The use of well-specified APIs and ABIs allows native opcodes to be used naturally. As an example, for IA32 the specified binary format is the SVR4 ABI. The use of ELF in kernel modules is quite natural to Linux, Solaris, and UnixWare. The outside “fringe” (like the MODULE entry points for LInux, the .dlkm sections for UnixWare, etc.) are easily handled by udisetup on the way onto the destination system. Because ELF is so well documented, it’s easy to convert to other formats during installation, such as the COFF requirement for OpenServer kernel modules. So it really does work to build a binary (and source is even easier) on any of those systems and run it on the others. • Are these all the UDI drivers that exist? No. They were picked to because they are av
Related Questions
- I am running Tomcat as an NT service. How do I write a command file or a batch file that should run a Java class (or a jar file) and restart the Tomcat service (so that the java class results can take effect)?
- Im having problems with the OpenGL verion under Windows. How can I run the Direct-X version Java 3D?
- Write once, run everywhere" is a familiar promise. How does this avoid the problems of Java?
