[MUD-Dev] Re: Real-world skills

J C Lawrence claw at 2wire.com
Tue Jul 24 17:09:04 New Zealand Standard Time 2001

On Tue, 24 Jul 2001 14:10:33 -0700 
Caliban Tiresias Darklock <caliban at darklock.com> wrote:
> On Tue, 24 Jul 2001 13:24:37 -0700, "Justin Rogers"
> <justin at mlstoday.com> wrote:

>> Its not that localization is a problem, its that most languages
>> or frameworks don't provide an easy mechanism to use and swap out
>> resources based on locale.  And I don't know of any that will
>> allow you to change the resources while the program is running,
>> (except for .NET of course).

> Use a resource DLL. These can be attached and detached
> dynamically. The Windows API supports this directly, so your
> framework isn't important and your language need only support the
> API -- which virtually all of them do.


> Now, once you LEAVE the Windows platform to port your client to
> the Mac or a UNIX box, things will get hairy. ;)

<<I've always rather liked the way that MS has rephrased the
language such that its a "Windows platform" and everything else is
an "OS" or "system".  So delightfully fuzzy.>>

Given care in managing/handling your symbol table dependencies (its
a questions of clean graph disjoints) under *nix you can use the
dlopen () and dlclose() calls to arbitrarily load/remove/swap shared
objects.  Typically this means using at least a two stage/level
approach with an adaptor to the shared object which manages the
references to the shared symbols.  The adaptor provides clean
interfaces such that there are no dangling references to the now
unwanted shared object when you want to change (otherwise the
refcount on the SO stays positive and the SO is not removed).

That said this is not often done as its rarely worth the extra
effort (which can become non-trivial) given how trivial it is to
exec() a new copy of yourself over the currently running image using
a different environment/locale.  I've often seen this latter exec()
approach used with a SHM block to handle state preservation across
the two execution contexts.

As far as handling message catalogs (which I've not messed with for
almost 10 years now), the base catopen(), catgets() and catclose()
libC calls seem flexible and simple enough.  I don't know how their
semantics match the Windows resource DLL model (I have no idea what
the Windows resource DLL model is).  

J C Lawrence                                    )\._.,--....,'``.	    
---------(*)                                   /,   _.. \   _\  ;`._ ,.
claw at kanga.nu                                 `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/                     Oh Freddled Gruntbuggly
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list