Staleness rating for this page: Very old|
If you've ended up here directly in a web search or otherwise, I'd consider going to my front page.
xCode Virtual Machine and Application Extension System
Please note that I'm not developing/supporting this anymore. However, even though it's not the most robust thing in the world and still has a few bugs, you can still do quite a bit with it, so feel free to "play around" with it.
xcode.tar.gz - Source
xcode.zip - Source and Win32 binaries
August 9, 2000: I've just uploaded a slightly refurbished version that I've been using myself for a while in development of my 3D world system after I found the old completely portable stuff too slow. It runs a lot faster and assumes a low-endian processor unless you define WEIRD while compiling.
April 29, 2000: I have found and quashed (I hope) a largish bug that prevented memory allocated during module running from being freed. Hopefully this new version should be free of the ghoulish leaks that characterized earlier versions. For anyone who is interested, you can now use my 3D world client/server system that uses xCode with a demo server on this machine.
March 4, 2000: Hey, look! He uploaded the version he has been hacking into useableness for the Unnamed 3D Engine! This drops all of the "pseudo-multitasking" and is designed to run efficiently in a threaded environment, one thread to running module instance. Check the manual; a bunch of the basic functions are changed.
July 3, 1999: Uploaded a new version with xnet UDP support and a bunch of utility functions, such as atexit() functions for modules and function callbacks to module functions.
June 21, 1999: I have begun distributing xCode under the LGPL license, which allows programs made using xCode to be sold commercially. I am also nearly done with coding an ANSI libc wrapper for xCode exportation use, minus wide character, locale, long jump category functions, and a few other functions. I will also probably add POSIX functions and other favorites later.
June 19, 1999: Thanks to Vadim Lebedev I now have the Linux version's networking glitches fixed. I have uploaded a new version, which includes that fix and well as bugfixes for problems in xcc and other things encountered while using xCode in my Unnamed Freeware Multi-User Networked 3D World Engine That Might Have a Web Site Soon.
April 22, 1999: Help needed; The test application running in server mode for UNIX does not work as it should (and does in the Win32 version). To any who know the ins and outs of both Win32 and UNIX socket programming, I would be very grateful if someone could look at the lib/xnet_win32.c and lib/xnet_unix.c in the source distribution and tell me why the network functions do not work identically for their respective platforms. I would also appreciate suggestions for a better name for the system than xCode (which is at least a domain name and probably copyrighted somewhere), as well as code additions (mail to firstname.lastname@example.org) in areas such as adding additional protocols to the xnet system, making the source compile for alternate platforms, and just reporting bugs.
What is it? From the manual's introduction:
xCode is a virtual machine system designed to be cross-platform and have
built-in support for optimized network streaming. Most processing is done
by a C library which can plug into any C program and allow for user
extension of that application, with access to specially exported functions
for a full amount of flexibility. A C compiler and assembler, xcc and xasm,
can be used to create modules of code for the xCode bytecode program language.
xcc [theoertically] is fully compatible with the ANSI C standard in the area
of language features, though there is no built-in standard library, as host
program implementors choose which default host functions to make available.
Benefits over existing options include the ability to use familiar ANSI C
instead of a bloated object oriented language (such as Java) or an
oversimplified scripting language (such as Tcl). One copy of a module's source
code loaded in memory is sufficient to support an unlimited number of
independent executing instances of that module within the VM library's built-in
multitasking system. A module compiled in xcc without the -nonet flag may be
run locally or streamed without any recompilation. When streamed, only input
and/or output portions of the code are actually transfered over the network,
minimizing bandwidth useage and therefore maximizing speed.
All this jazz copyright Adam Chlipala 1999.