🚀 go-pugleaf

>SP>6.  VB/DOS, like VB/Win, uses Far Strings only.  The vast majority of all
>SP>commercial addon packages already use Far Strings so this should be no
>SP>problem for most people.  FWI -- Far Strings allow VB/DOS to use all the
>SP>DOS memory your machine has available, near strings are limited to 64K
>SP>of total string space.  Far strings have also been highly speed tuned for
>SP>real-world code so, in most real (as opposed to contrived benchmarks)
>SP>apps, Far strings are at least as fast as near strings.
>
>I can't argue with most of what you've said here, and I have no desire to
>bash VBDOS before I've had time to try it out, but this seems a bit
>misleading to me.  I have used nothing but far strings for some time, even
>to the extent of storing "literals" in a file and reading them into far
>strings to keep them out of DGROUP, and I don't get anywhere _near_ my
>full memory capacity.  Each far string, unless you have changed this in
>VBDOS, has a DGROUP-based handle.  Therefore, you are _still_ limited
>by DGROUP even using all far strings.  This may be unavoidable, but people
>need to be told.  It is frustrating to hit the DGROUP celeing, check your
>far string space, and find you have over 100k left.  It is very _rare_ to
>be able to use your full far memory for far strings.  One way to do it is
>to use really long strings instead of a lot of short ones.

You are, technically, correct.  However, if you're really running out of
far string handles in COMPILED .exe files, I'd be shocked.  I've never
heard of anyone using that much string space.  The amount of dgroup space
used by a far string handle is microscopic.

Thanks, Steve