Quote:

The CALL command would by nature of not having the tokenizer, have to only support pretokenized scripts.



An additional caveat is that none of the scripts can contain Execute(), which might cripple the functionality enough that the space saved by dropping the parser is not worth the bother.

Quote:

alright, now we are talking!
KiXcompiler would be soo hot.
it could take advantage of the MIDL already out there, couldn't it?
that is, Ruud would "only" need to add kixtart language specifications.
GCC could also support kix, thus even unix, linux and OS X binaries could be done.

CKiX or even KiXc - KiXtart Compiler



Hah, interesting idea

A Windows KiXtart compiler would be feasible I guess, though you'd need to develop a library of helper functions which would be included at link time to support KiXtart built-in functionality.

However I'm not convinced that KiXtart for *nix or OS X is particularly useful. These operating systems already have a number of tools which are mature and far more appropriate to their environment. To port KiXtart you'd necessarily have to remove inappropriate functionalilty and emulate a lot of the stuff which is provided to KiXtart via Windows API.

I imagine most people use KiXtart not because it is the best all-purpose scripting language (it isn't!) but because it is probably the best light-weight scripting languages for Windows administration and logon processing (a definate yes!) and is getting better with each release. It's also very easy to learn and kind of cute.

If you manage multiple environments and you want a common code base or set of skills you'd be better off using Rexx, Java, PERL, PHP, KSH/BASH or one of the cross-platform BASICs, or maybe go straight to C / C++ or whatever the current flavour is.