>> The PicoLisp family of processes could easily be achieved under
>> Windows using mmap-ed shared memory, IPC, and spawn()s to get it all
>> started. It is just a different model than the old fork() mechanism
>> of UNIX. It might be worth looking into for PicoLisp as a future
>> enhancement, then a PicoLisp family of processes could be shared
>> between separate computers, a la Erlang.
> Yes, that's interesting. I don't want to care about Windows (Windows
> is obsolete in all interesting segments, remaining only on the
> desktop), but in fact I was experimenting with mmap'ed versions of
> PicoLisp in the past.
no idea how to go around solving the fork issue which is probably the
main issue with porting picolisp to windows. Locking has problems on
NFS iirc but that's a system configuration issue rather then windows
issue (simply use the right filesystem).
I don't (unfortunately) agree with the statement:
Windows is obsolete in all interesting segments, remaining only on
It appears to me that it's significantly more relevant then any bsd or
sparc ports. Well, I kind of agree with the statement only because I
have no interest in running windows unless there is a good commercial
reason for the effort.
BTW It is rather easy to develop and test windows applications under
linux with wine and msys. Works like a charm if you don't use obscure
winapi functions like asynchronous file locking.