Recall that Factor uses ANSI C I/O functions (fread, fwrite, on FILE* pointers...) unless there is an OS-specific I/O subsystem implemented.
The ANSI C I/O functions don't perform any buffering with the (already slow) Windows CE console, which results in very slow output. Having console I/O go through a buffered I/O layer which uses native Windows APIs has improved performance considerably. Words such as
seeno longer make you wait and watch as individual words are printed out.
Also, a native I/O layer means networking (TCP and UDP) may be used. There are other, more minor features as well (creating directories, removing files, etc).
Unfortunately, we don't have non-blocking I/O on Windows CE, because there is no general I/O multiplexer like IO completion ports on Windows or select() on Unix. Console and file I/O is always blocking, and network I/O can go through a Winsock-only multiplexer.
In the future, I'll write a small piece of C code which is linked with the Factor runtime. This code will start a network multiplexer running in its own thread; the thread will post events to an event queue. Then, the Factor event loop can use
WaitForMultipleObjects()to multiplex over the I/O event queue and the UI event queue.
However, for now, I'm done with the CE port. There is still a bug in the ARM backend preventing Chris Double from bootstrapping Factor on his Nokia n800; I'm going to look into this next. In Factor 0.92, I will implement mark/sweep/compact garbage collection for the oldest generation, which will reduce memory usage on Windows CE, and I will also look into getting the UI running there.
Factor will be the premier high-level language for Windows CE development!