Here is a new build. This one comes with quite a few internal changes. Although it has been tested quite a bit, a few compatiblity problems might have gotten through. Please report any you find. You will also now find a link to the changes over on the downloads page.

The main things to watch for are:

To specify an empty string value, you must use a set of empty quotes "". Simply not including any parameters at all, will not work. Example: HotListName "". That will produce an empty title bar for the Popup. However if you were not to use the quotes and have nothing, it would not work.

A specific problem people are having is using the incorrect syntax with popup.dll like this: *Popup "Utils" !PopupFolder:"$AppDir$\Utils" when the format should be: *Popup "Utils" "!PopupFolder:$AppDir$\Utils". Notice the placement of quotes around the whole !PopupFolder section. You must do this for it to work.

Otherwise everything should be good to go.

Enjoy.

The new mailing list is up. Thanks to Bryan Kilian of wuzzle.org for providing the list server for us. Head over to lists.purels.org to sign up.

The old mailing list and webboards will stay up for a little while during the transition, but will be removed eventually. Please unsubscribe from the old lists and join the new one.

Thanks.

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.

Here is a new build. I really hope all of these problems have been fixed. So far things are running fine on my system (but that isn't saying much). This build also re-enables the PureLS specific startup items that were disabled in the last test build.

The test builds that were posted on the mailing list have been removed from the archives so that people do not continue to download them.

It looks like the startup.dll in the latest build is causing more problems. Mainly apparent on Windows 9x machines. For now I suggest everyone move back to the previous build if you need to use the startup.dll functionality. If you do not need startup support, just delete the startup.dll and continue using the 01-03-27 build.