Has there been any previous suggestion (I've already looked and can't find any...which doesn't mean it doesn't exist) regarding kix and i/o streams.
Specifically, modifying kix so that it will accept either a file or a generic i/o stream. If it's able to accept a stream, then it would be trivial to provide custom encryption/obfuscation/protection for scripts.
Loc: Harrisburg, PA USA
More info about using streams.
quote:Note that files with single-character names cannot contain alternate streams because these file names are treated by Windows as drive letters. When a drive letter is specified with a relative path, a colon separates the drive letter from the path. When there is an ambiguity about whether a single-character name is a drive letter or a file name, Windows will assume a drive letter if the string following the colon is a valid path, and a file name otherwise. This will occur regardless of whether the drive letter or file name is valid.
Loc: Leatherhead, Surrey, UK
Ok, for anyone else (like me) who saw this and got interested - NTFS streams are not the answer.
When Stevie is asking about reading from IO streams, what he is specifically referring to is what in the *nix world would be stdin. This is normally attached to keyboard input but can be attched to the output of another program where the operating system supports pipes.
NTFS streams are not IO streams as most people understand them They are simply named file sections. You cannot use them to communicate between processes, or "pipe" information.
Note, KiXtart can read piped input using GetS, but it is kludgy and there is no way to reconnect input back to the keyboard.
Some ways of achieving this:
Support for named pipes would be interesting, however these are not fully supported under Win9x.
Anonymous pipes are another option. These are supported by (later) versions of Win9x, but passing the handle may be tricky.
KiXtart could read the script from stdin, and when the stream terminates reconnect stdin to the keyboard.
The decrypting program could pass the script directly to KiXtart via COM automation.
The bottom line on this is that it would allow you to send a script to kix32 without that script needing to be a file.
A possible usage of this would be to have an encrypted script file decrypted by some external process (kixcrypt perhaps??) and then sent directly to kix without having to create an unencrypted version of the file.
It would make script encryption/obfuscation even more secure.
Another possible use would be to dynamically create a script and spawn it via a second instance of kix without writing it out to a file first.