STR
***
This is FASMLIB string library. It is rewrite of Fresh's string library (by
JohnFound, decard and roticv). It is intended to ease working with strings (one
of main drawbacks of low-level lanuages like asm or C)

I have decided to make this library required part of fasmlib, eg. it has to be
included and initalized for other modules to work. This is because many modules
work with strings, and without this we would need to check if library is
initalized in each such routine. And every bigger FASMLIB project would use it
anyway. In extreme case you CAN use some parts of FASMLIB without it (as much
of it as possible until efficient :] ), but lot of things won't works, see
"note"s in descripion of things, it should list modules that are needed for
routine to run. This means you don't have to list it as required in notes

"string pointer" means "pointer to null-terminated ASCII string" in FASMLIB.

This library works with "string handles", which are not string pointers. String
handles are numbers from 0 to FFFFh. Higher numbers are treated as string
pointers (discussion by the EOF). Advantage of this approach is that string
buffers doesn't have maxmimal size). Disadvantage is that you have to call
"str.ptr" to get string pointer from string handle.





<<< TODO >>>
TODO - str.uninit frees all alocated strings





DISCUSSION: Pointers in range 0-FFFFh cannot act as string pointers
-------------------------------------------------------------------
- there has to be way to internally differentiate handle from pointer
- mem.alloc always returns higher values
- code is run higher in memory on most systems.

Only problem is DOS, where data (theoretically) can be under 10000h, whether
placed in code or allocated using MS-DOS allocation. So to write code which
runs fine in DOS stick to following rules:
- preferably place inputed strings into buffers returned by mem.alloc before
  using them with str module
- don't place string constants into code (note that constant strings declared
  as arguments to libcall are created in data section (using "idata"))

DOS support isn't running now anyway, and i believe we will have this solved
somehow (there will have to be some mode_init routine anyway which will start
unreal mode there, so that one can copy data somewhere to >1Mb region if it is
under, or something).
