It is the time for new beginnings, and so I'm going to try to give one to PureLS.
PureLS has been fully opened source for a while now, and I hope people have found that useful. However, there has not been any outside input to the code which I find disappointing.
As I have been the main developer on it thus far, PureLS has a pretty defined code style to it. It is a pretty different from the normal code that one sees since it uses all TCHAR.H defines, and perhaps this is the problem causing people not to understand it.
In any case, I am looking for other developers who specifically want to code in the same manner I have started. Using the TCHAR.H defines and make sure everything is UNICODE compatible, Thread safe, and is well written, compact ANSI C code.
Over the next while I plan to start releasing UNICODE release build archives along with the current set of archives. However, since I do not want to have to provide a lot of translation layers, I need to finish the other major sections of PureLS to remove the remaining LSAPI.DLL legacy code that keeps it from completely supporting UNICODE.
This is a bit of work, and the more help I can get from people, who see the same goals as I do, will be appreciated and will help make this happen sooner.
The following are the major section goals that need to be met.
1) - A comprehensive GDI function set which is well written and extensible for adding multiple file formats.
2) - Rounding out the FILE function set with "write" functions to supplement the current "read" functions.
3) - Creating a new bang/ script/ logging/ information system. (this is the phantom "core.dll")
4) - Cleaning out the Legacy LSAPI.DLL code and pointing all of its functions as wrappers to native pLS routines.
5) - Removing all but essential shell messages from the message handler.
6) - Supporting alternate development environments (compilers).
So, where I could really use the help is in the GDI department. Anyone who is quite versed in Windows GDI and knows (or is willing to dive into) UNICODE development is most welcome.
I would also appreciate people who have a good idea of general shell functionality that would be happy to come up with new ways to extend our internal Shell communications. (Both core-module and module-module communications.)
If you are interested in helping out, I would be glad to talk with you, but better then words is code patches/ submissions to PureLS. Really though, if you want to put in some time on PureLS code, and are into quality over quantity code, please help out. I am not looking for someone who can make a ton of changes fast, but maybe just a small change/ update now and then that are really well done and makes a good addition to PureLS.
I myself plan on tackling numbers 3, 5 and 6. However, number 3 could easily use support from others as well. Also, while I will be able to get number 6 working in one or two other environments, if people have their own "pet" compiler it would make more sense for you to create a workspace and build environment for it, and send it in, rather then myself trying to figure it out.
I hope to hear from people. If not, no worries, PureLS development will continue, but continue at the slow pace it has always taken. I am fine with this, I just know things could be better if more people worked on it.
But do realize, I am pretty determined to keep the code style/ format how it is now (look at the code for purels.exe and plsapi.dll as examples to what I mean), so expect to try to work with me on that. I hope that does not scare too many people away! :)
To make a long message longer, in short I am looking for other developers who want to help extend PureLS and are willing to continue with the current code base in its same format.