Donate to support SBCL for Windows |
I am maintaining a friendly fork of SBCL for MS Windows, which is on its way to integration into the mainline. It's a further development of Dmitry Kalyanov's work on multithreading SBCL for Windows. I've added some features beyond mere multi-threading, both essential ones (e.g. interrupts, making SBCL useful with SLIME's multithreaded communication style) and others (e.g. 64-bit Windows port, making possible to use large memory on modern systems within a single SBCL process). Many of these features are described at the project news page in more details.
Paypal, the most convenient way to donate:
Direct payment with Visa and Mastercard is possible with Payoneer's Card Load Page (min $0.01, max $1000.00).
Credit cards, PayPal, wire transfer and many other alternatives are accepted at Plimus secure order page:
Yandex.Money: account 41001118069549 can be useful to some people as one more alternative way to make a donation.
Since 29 December 2011, Paypal is accepted. I keep alternative payment methods available, as they still can be convenient for some people. Payoneer and Plimus helped me to sell my software for more than 4 years, without any dissatisfied customers, conflicts or disputes.
Up to Summer 2011, I was able to use a revenue from in-house SBCL-based application development to fund this project. Now I'm relying mostly on your donations, as I continue to provide up-to-date binaries for new SBCL versions, (that is, to track and merge upstream SBCL changes). There are also some plans for future development which could be made possible this way, but I'll avoid making promises for now: let's see if we can support the minimal goal of project survival first.
If you need some hand-holding services, or you have a feature request for SBCL on Windows, feel free to negotiate with me. That could be as useful as a generous donation.
Anton Kovalenko is not affiliated with SBCL development team, or Dmitry Kalyanov, or other parties involved in SBCL development, except by continuous exchange of code and ideas. If you want to support SBCL project as a whole, or some other aspect of it that is outside of my project's scope, I'm not the right person to accept donations for that. Nikodemus Siivola's crowdfunding campaign for SBCL threading improvements could be a good starting point in that case.
Some generous people who heeded my call for donations:
$733 donated since my initial request (at 2011-11-29), according to notifications I've received.
I recognize that someone might prefer either more or less information on their donations being published. Until I discover a way to ask for this preference in advance, I had to select some sensible default, which is that:
The list is ordered chronologically.
Here is a list of major changes introduced by my commits for more than a year. I tried to avoid going deeply into obscure internals, focusing on externally visible effects; dead ends that were rolled back and continuous, boring tasks are mostly excluded as well.
I'm putting it here as a kind of public report that is also useful to grasp the direction of future project development. Some subjects mentioned below deserve more to be written; therefore, expect some hyperlinks to be added into this section in the future.
2010-08 Overlapped I/O for sockets (reader/writer threads of SWANK are able to work). Some socket error handling. Non-blocked socket support. SBCL now runnable on Wine.
2010-09 Interruptible sleep, reimplemented with waitable timers.
2010-10 Simple streams mostly work. Added memory-mapped simple-streams input with winapi-based mmap emulation. Support for large files. Opening //./PhysicalDrive0 becomes possible. Overlapped I/O is requested for newly-opened devices and files. GC, interrupt, thread-related improvements. More filesystem fixes for non-file devices. With-timeout implementation using a hidden watchdog thread and waitable timers. Serial ports can be opened, read, written, and waited for readiness. Run-program passes comman-line arguments correctly. SB-TIMER port.
2010-11 Prevent resource leak by ensuring that sockets are closed with closesocket, not bare CloseHandle. Migration of thread-base pointer from TIB arbitrary data field to TLS slot 63, so SBCL can actually own it. Initial support for stdcall callbacks. Initial support for callbacks from foreign threads (using Windows Fibers). Some linkage table quirks fixed, so it becomes fully supported on win32. Various changes to ensure lazy memory commit for heap and control stack.
2010-12 Avoid getaddrinfo in SB-BSD-SOCKETS, as it can be GetProcAddress'able but not grovellable. Introduced hidden (daemon) threads. Stdcall name mangling is not required any more, whether we write an x-compiled source or a normal source. Code simplifications for futexes, interrupts, etc. Threading and GC: communicate thread context data cooperatively, no more SuspendThread. Foreign function calls to SBCL runtime: new linking method. Runtime and core can now be rebuilt and replaced independently. Data Execution Prevention compatibility. Copy-on-write memory-mapped core on Windows. Executable name might be unrepresentable in ANSI charset: not a problem now. Automatic GC happens once when the threshold is reached, not once-per-thread-per-trigger.
2011-01 File sharing modes corrected to avoid sharing violation errors for concurrect access where appropriate. Unified linking against foreign data and code: references to SBCL runtime now behave much more in the same way as shared object references. Use winapi-based futexes instead of generic pthread-based futexes: one layer of emulation goes away. Provide sensible default for --core using the runtime module name, so SBCL_HOME is not needed anymore. Some optimizations in condition variable implementation. Use MEM_WRITE_WATCH for write barrier on non-mmapped pages. First steps to correct asymmetric synchronization. An attempt at sensible CL:LISTEN for console I/O. We don't crash on binding stack overflow, we handle it, like on other platforms.
2011-02 Support POSIX-style unlocked broadcasts in pthreads_win32; use them where appropriate (we have no wait morphing here, so avoiding extra context switch is good). Implicit OS thread pooling (resurrection). Wall-clock mode statistical profiling support with SuspendThread. 64-bit Windows port is now runnable. One more rewrite of threading/GC/FFI synchronization layer, resulting in a cleaner implementation of asymmetric synchronization.
2011-03 Trivialized pseudo-atomic sections for safepoint-based builds: they are atomic here. New inter-thread synchronization mechanism for GC (fewer context switches and waits). Various fixes for 64-bit Windows: alien callback support, math routines, word size issues... Introduced alternative frame-pointer chain for FFI call contexts: -fomit-frame-pointer does no harm to lisp backtrace on safepoint builds now. Windows file handles are used instead of CRT descriptors now (in the core SBCL, not in sb-posix).
2011-04 RUN-PROGRAM reimplemented with CreateProcess, adapted for recent lowio-to-handles revolution. Foreign thread callbacks added for 64-bit Windows as well. Prevent XMM context corruption in some places.
2011-05 Support 64-bit WindowsXP, which rejects PAGE_EXECUTE_WRITECOPY. Initial take on pathnames longer than MAX_PATH. More RUN-PROGRAM fixes. Fix an incomplete redefinition of FILE-POSITION in sb-simple-streams, thus reenabling FILE-POSITION for Gray streams.
2011-06 System error message formatting improvements. Explicit gc-safepoint calls went away completely. Added C-side code to allow using some other file than currently-running SBCL as an executable prefix. Use CreateProcess(NULL,...) again to get :search t behavior in run-program, taking extra measures to make it deterministic this time.
2011-07 Unified error handling in win32_unix_* I/O wrappers, to avoid interpretative differences for overlapped and synchronous completion. No save-fp-and-pc on gc-safepoint builds by default (when building SBCL itself): we shouldn't need it when we have a backup frame pointer chain.
2011-08 Some patches start getting into mainline. Some conflicts on merges, but fewer than expected. Real implementation of over-MAX_PATH namestrings. Directory operations don't use MSVCRT anymore: everything ported to kernel32 calls. UNC pathname representation altered, so it becomes possible to distinguish //C/Thing and C:/Thing. Added Control-C handler, making it as similar as possible to SIGINT handler on unix. Fixed thread and fiber lifetime management to allow foreign callback invocation from TLS callbacks of loaded DLL. Allow another executable with embedded core for --core argument.
2011-09 Fixed stepping, breakpoints, non-encapsulation traces on Windows. A huge pile of my own dead code removed. An attempt to handle control stack overflow without crashing (still fails on Wine in some circumstances).
2011-10 Merged wide fixnums from mainline. Fixed some local issues; tracked down a non-local bug (ROOM issue). Enabled core compression support for Windows (now used for my stand-alone executables). Fixed an accidental limitation of dynamic space size on 64-bit Windows to 4G.
2011-11 Fixed various non-Windows issues, starting with threaded Linux builds. Ported sb-dynamic-core (prepopulated linkage table) to Linux/FreeBSD 64/32-bit multithreaded/unithreaded combinations, except */64-bit/unithreaded. Merged Nikodemus Siivola's threading code (fewer problems than expected: implementing futexes was a right decision, as it turns out).
At this stage, your donations and support are very important. However, one thing is even more important for SBCL on Windows: restoring its reputation on that platform.
Since the appearance of Windows port, a huge pile of material accumulated on the Net, pointing at the port's shortcomings, problems, and bugs, up to the point of discommending its use altogether. Many of those problems are already solved by this project, but it can be a long time until it's known widely.
If you have a positive experience with my version of SBCL for Windows, please recommend it to other users: share a link to the project's wiki homepage on github (or to the page you're reading now).
If you found a problem or want a new feature in SBCL for Windows, feel free to share it as well. I recommend to use an appropriate bug tracker for this kind of content to ensure that your future readers will get up-to-date information on fixes and improvements related to the problem: either my issue tracker for SBCL/Windows fork, or the mainline SBCL bugtracker.