Just bumping this thread to get thoughts of others... Ive been scripting in Kix since about 1999. It started like many as simple logon scripts, but eventually became much more. Just about every administrative function in our enterprise (1600 desktops, 85 servers, 5 sites) has some custom kix script or system managing it. I don't use Kix because it's the only thing I know and am unwilling to use something else...I actually know and use VBScript, Powershell, AutoIt, and also VB.NET. I use Kix because nothing else can do what it does.

I just recently revamped our startup/logon and software distribution scripts (all written in Kix) to work with our latest Windows 7 deployment. Everything works great.

However, moving forward I'm somewhat reluctant to use Kix for upcoming projects because I simply cannot predict the future of Kix. Yes it works now, but once we get to pure 64-bit environments (such as WinPE) we're going to have problems. Furthermore, in larger enterprises we have to think about supportability by other admins.

For instance, I just rewrote our WSUS management scripts for Server 2008 R2 and I decided to do it in VBScript. Would Kix work BETTER? No question about it. But because this thing needs to be supportable moving forward, by somebody other than me, I just felt that I needed to use a language that I know will be around...one that people can find training in.

I'm also doing a new AD user request/creation system where down-level IT staff can request new users through a a GUI, which drops a request file on a server, and then a backend process picks that up, creates the user(s), mailbox, home directories, profiles, provisions groups and emails the requester when it's done. Naturally I'd want to do that in KixForms and Kix. But again, with an unknown future, I decided to use an HTA front end with a Powershell processing script scheduled on the server.

I'm finding that with most of my upcoming scripting efforts, I'm looking to powershell first, then VBScript, then if none of them will do it I resort to Kix. In most cases I spend hours figuring out how to make Psh/VBScript do what I could make Kix do in seconds. But that's fine. I've told myself I will develop whatever libraries I need to get PSh/VBScript where Kix is now.

But sadly (for my needs) Powershell and VBScript have three major show-stopping flaws...

Script compilation. Not available in Powershell or VBScript without proprietary third party methods. This is huge for me. I'm not saving any credentials in scripts, but I do a lot of administrative type scripts that access various network locations for config or control files. While I secure this stuff fairly well, it's nice to know that some of our more savvy IT staff cant just look at my source code and glean key directory names or AD group names and see whats happening behind the scenes. Further, script compilation allows more effective use of function libraries.

Include function. No way to do this in VBScript at all...other than a very cumbersome ReadAll() method. Powershell does somewhat have an include (simply call another PS1 file that contains your function) however this requires that the person running the script have read access to your function library. Not cool.

Native INI support. INI is simply put the most simple and effective way to provide configuration data, or input/output any information. Yes, XML is available, but one ReadprofileString() command replaces about 10 lines of VBScript XMLDOM code. Ive written my own INI processing code for VBscript, but without a viable Include function for VB, it's almost impossible to maintain.

Anyway, those are my three big show-stoppers..and ultimately what have me coming back to Kix every time. Anyway...probably not any new information for any of you...just felt like I needed to vent because this is a fairly weekly frustration for me. About 60-70% of my job is scripting. And Kix is just simply the best tool for the job in almost every case...I just wish I knew whether it was going to be around a while longer.



Edited by sixdoubleo (2010-12-17 06:40 PM)