So I chatted with Alastair Bridgewater at tonight's Boston Lisp meeting; here were the big three showstoppers
On a POSIX (e.g. linux) system, you open a file and pass its id to select() when polling for events. On MSWin, you get one file handle for reading and writing, and another file handle for event processing... Serve-event is used for useful things like the Slime repl.
- memory map
Traditionally, sbcl allocates the maximum memory as a contiguous heap at startup. This is dicey on MSWin since MS wisely chose to make DLLs relocatable instead of position independent (a la unix .so's). The DLLs often fragment the memory address space so badly that sbcl fails to allocate its heap. This seems to affect some users more than others, depending on which DLLs are loaded where; sbcl simply won't load when it happens; it often takes a reboot to clear (standard MSWin cure-all). The fix is to make sbcl work with several heap slices instead of one contiguous block.
- external formats
"Real OSs" use \n as the end-of-line marker. MSWin uses \r\n (possibly because old macs "thought different" and chose \r). SBCL doesn't read lines properly on MSWin, resulting in the \r appearing as if it were text. This may or may not be a problem for you depending on editor settings, usage requirements, etc.
Alastair says all of these have known solutions; he just hasn't had time to finish them. He submitted rough sbcl patches for one of them several months ago, but nobody picked it up and finished it.
Most other known bugs were platform-agnostic (or at least universally broken).