A snag here, two there, but the code is progressing. Been pretty busy but should have a new build out shortly. Just trying to work around some issues. You should expect delays as common place by now though. :) The next release will sport a new startup.dll and support for Shell defined startup items, which will be defined in the purels.cfg file. All optional of course.
I have also been fiddling around with grd's grdTray.dll systray module as it crashes on recycle when running under PureLS. Basically, the module is incompatible with PureLS, as it requires the Shell to allocate and free memory for it on recycle, which is a new feature in LiteStep, but unsupported in PureLS. So that is that for now.
There are some core changes for extending module functionality coming down the line, so things such as a Module needing to store data over a recycle and the likes will be supported under PureLS. However, at this point the final format for doing that has not been decided upon. In the mean time if someone wants grdTray to work, they will need to simply change its tray saving functionality when it receives the Shell message to save its data to the registry as Maduin's systray.dll does (grdTray already supports reading the data back in from the registry).
On another note... it seems that the "pure" in PureLS is not so pure at the moment. Apparently the BOOL data type and TRUE, FALSE identifiers are not C compatible. Neither is exception handling. Anyway, I'm sure the critics will get a big kick out of that, but our main focus right now is to get this release out with the updated startup.dll, then focus on supporting free compilers. At this point the code will always be a little tainted, as I don't see any solution to not use exception handling when loading a 3rd party module. That stability is needed. Input on the matter is welcome.