Hans-Christoph Steiner wrote:
probably it would be easiest to just prepend "_" and keep the 0x notation.
or even simpler: use "x" instead of "0x" (of course this is not the conventional C-way of encoding hex-values)
Yes, that sounds good. So then you couldn't have an object named _0x2a for example. I think that is a livable comprimise.
the best thing (which i tried to explain last time) is, that you _can_ have both [_0x2a] and [*], _if_ the setup-function and the filename do not adhere to the very same logic! (it was just me who was thinking into the wrong direction). filenames don't have the "do not start with numbers" restriction. so the [*]-external can live in a "0x2a.dll" with a setup-function "_0x2a_setup()", while the [_0x2a] external would live in a "_0x2a.dll" (with the same setup-function! but the entry point to the library is on a per-file basis so we don't have to care). the only remaining problem is the [0x2a] object....which we forgot and which still cannot be loaded.
but in theory it looks like that (with "*" being an invalid character, and X being the escape-sequence of this character)
[X] X.dll X_setup() [*] X.dll _X_setup() [_X] _X.dll _X_setup()
_if_ we guarantee that X starts with a valid character (not a number), this does not necessarily help us, since then we can do: [*] X.dll X_setup() which really is the same as for [X].
if X does not start with a valid character (e.g. "0"), then we have a problem anyhow with [X].
so what's the conclusion of all this?
probably it would be simplest to use tg's external loader hook and just write a "hexsetup" external and a "zexsetup" external and ... ;-)
fmg.asdr. IOhannes