Because I'm about to go away for the weekend - the new Weasel would
not be available for two or three days from now unless I released
it right now. I've therefore done a final build on it this evening.

You can get it from

         ftp://ftp.pmoylan.org/Weasel/

I strongly suggest that you read the README file and the CHANGES.DOC 
file. For people who want to continue using INI files the changes are 
relatively minor, although there are some changes. (Including one that 
might actually solve a memory leak, although I'm still uncertain that 
there ever was a memory leak.) The big change is that both Weasel and 
Setup can be run with a parameter "-t", which tells them to use 
WEASEL.TNI instead of WEASEL.INI. (And, in the multidomain case, to use 
DOMAIN.TNI for the domain data.)

Because of the hurry to make this available, I haven't given this 
version as much pre-release testing as I normally do. In fact, I can't 
even run it on my own server until a bit later, because I won't be here 
to observe the result. It might be wise to run it on a backup server, or 
using nonstandard ports, or something like that, to make sure that it is 
working for you before putting it into production. Naturally it has had 
some testing, and I believe that it is OK, but the changes in this 
version are fairly major changes, and as a general rule the more things 
you change the more likely you are to introduce bugs.

One thing to beware of: there is no guard, apart from the file system's 
file-sharing rules, for the case where Weasel and Setup want to access 
the same TNI file at the same time. The OS/2 system INI-handling 
routines look after this for INI files, but of course there is no OS 
support for TNI files. I could solve this problem, with some difficulty, 
by turning some of my TNI-manipulation code into a DLL, but so far I 
haven't done this, and I'm not sure that I should do it, for the 
following reason: to make the DLL work I would have to cache data in the 
shared memory region, which brings us back to the same old problem that 
there is a shortage of shared memory. In other words, making provision 
for simultaneous access by two programs would bring back the problem 
that I was trying to solve, thus making the entire exercise pointless. 
Any solution needs to deal with the case where there is a particularly 
bad shortage of shared memory, as for example on Massimo's server. (We 
don't yet know why the problem is so much worse in his case than in 
anyone else's case. My guess is that either there is an unusually high 
number of DLLs being loaded, or that there is some application - 
possibly even Weasel - with a memory leak.)

I have some rough ideas about minimising this problem by keeping track 
of the age of each shared item, and throwing it out of memory when it 
hasn't been accessed for a while. The details are, unfortunately, 
tricky, and the most obvious implementation would actually increase the 
shared memory usage, so I might never implement that approach. Another 
possibility is simply to keep two copies of the TNI file, with 
occasional replacement of the master copy by the updated copy. (The 
INI-handling system functions do something like this.) I still need to 
check out the fine details of what will happen if Weasel tries to access 
the TNI file during the "window" when the file is being rewritten. Most 
software doesn't have this problem, because either the configuration is 
changed only when the program is not running, or the configuration 
editor is part of the main program; but for a server program you don't 
really want to shut down the server while you're doing something like 
adding a user. In the worst case, I might have to adopt the approach 
used by most designers of server software, which is to combine Setup and 
Weasel into a single program. I've been trying to avoid doing this, 
because it would double (or perhaps more) the memory footprint of 
Weasel, and I really detest bloated programs.

Anyway, that's a longer-term issue, for when I'm able to devote a few 
hundred hours to a major design change. For now, the reality is that 
there is a very low probability that Weasel will want to access the data 
just when Setup is changing it, and we can afford to live with that risk.

-- 
Peter Moylan
http://www.pmoylan.org