Apparently my previous comment about PureLS not being so "pure" was mistaken. We use all uppercase BOOL, TRUE, FALSE which are Win32 defines, and not their lowercase c++ data type equivelant. So, we are safe on that point. As for our use of exception handling, once again we are ok, since __try{} __except(){} are also not c++ specific, but defined in the Win32 platform. Thanks to Maduin for pointing this out. Aren't we all so happy now? :)

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.