(Hey THIS is FUN)
2014-01-07 08:52 PM
Kix32.exe is too large, I use an old version.

I have been grave robbing again and I have unearthed this rather interesting thread! I don't want to continue the discussion of whether kix32 is too large etc as I think that argument is irrelevant as kix32.exe is quite small compared to a lot of things out there.

But I would like to ask two questions about things that I picked up here.

Tokenising. With emphasis on reducing file size (not obfuscation) I still have not got around to tokenising my scripts, due to so many other more urgent things to do and just general lack of time. However I wanted to ask, is it possible to tokenise the scripts so that the main script calls the pupils script, the staff script etc? I assume that it does this as most people probably have scripts calling other scripts.

What really prompted me to raise this question is the suggestion that people are copying the kix32.exe file to the local machines and running the scripts by calling the kix32 locally. I have been running the scripts using the logon, startup etc in gpo and calling the kix32 from there.

Howard Bullock

I store Kix32.exe, crc32.exe, and 70+KB of script code on the client that is executed globally by 35,000 clients daily. I much prefer the added functionality in Kix32 and with it staged locally, I have no issues that site.

If you want to see my batch file for launching this it is here: LOGON.BAT (the overkill version)

if Kix32.exe or the scripts are altered or otherwise corrupted they will be replaced because they will fail a CRC32 check. If I add updated code on the DC again the locaaly cached files fail the CRC and will be updated.

You must not be doing very much with your code if you are elated with 3.21.
Home page:

Maybe I should look into doing this. I am finding that with some netbooks that we have, the login script takes ages to run and this might help speed it up. I never considered copying all the scripts plus kix32.exe to each local machine as the scripts and kix executable are not large by today's standards, but seeing two people in this thread mention copying the executable to the local machines, I am wondering if this is commonly done.

Does everyone else tokenise their scripts and then copy the tokenised scripts and kix32 exe to each local machine to run from there?

I am happy to lend anyone a pair of my gloves that I used to dig up this decade old thread! Its interesting what you find browsing through the website. This thread still has relevance today even with our gigabyte speed networks!

Glenn BarnasAdministrator
(KiX Supporter)
2014-01-07 09:14 PM
Re: Kix32.exe is too large, I use an old version.

There are a couple of considerations here.

I tokenize many of my scripts, mostly to prevent unauthorized modification. Any script that we support commercially is tokenized. The performance difference of tokenized/plain text in most situations is negligible. You might see worthwhile improvement of tokenized scripts over low-performance WAN and dialup links, although these are becoming increasingly rare nowadays.

With KGen's BAT reformat capability, I also use the .BAT extension for many Kix scripts that are NOT tokenized, allowing me to distribute the Kix script and a copy of Kix - they both run from the same folder without any prep. .BAT is a normal extension to execute from the command line, so this form allows me to avoid having to register any extensions.

I do install Kix32 locally, but only on Servers and Admin workstations, where we rely on many of our administrative scripts to be available - Wus/WusSvc, tsAdm, LogMaint, Cleanup, and several other diagnostic and administrative tools.

As for installing Kix32 and scripts on every workstation, this quickly becomes unmanageable as Kix and the scripts are updated. Many of the sites I support have >5000 workstations and as many as 30,000. Managing the updates on all those compared to Kix32 and the login scripts on the NetLogon share is a no-brainer in favor of a single (replicated) location. The one partial exception to this is our Universal Login Script, which caches the INI file on the local computer. We found that repeated queries to the INI file over the LAN or WAN impacted performance. With the INI file local, it was cached in memory and was very fast. The script does have some overhead in determining if the local copy is current and consistent with the Netlogon version, but again, negligible.


PS - Grave robbing is right! I think that 10 years is the record for necro'ing a thread! \:\)

(Hey THIS is FUN)
2014-01-12 01:48 PM
Re: Kix32.exe is too large, I use an old version.

I will have to think about this. My networks are small. Less than 100 computers at each network. Having looked at the issue further, I don't think the problem is the network as in copying over. I believe that the main slowdown is 1: deleting temp files on login and 2: installing Firefox profile updates and things like that on login.

What I am going to do first is change the setup so that temp files are deleted on logoff and I need to find a script that will allow me to calculate how long each line of code is taking to run.

I am going to be looking at buying impero software that will allow me to update flash player, firefox, java as well as all windows updates and this will eliminate the problems of updating firefox, although it won't fix this specific issue as the firefox profile needs to be updated on login as the profile is user specific.

It was just interesting that several people in this thread mentioned copying the kix scripts across. I might do this as I don't update the script more than once a month I would guess, and I certainly don't update the kix executable more than once every two years. But I am assuming that if the kixtart script is running and the running of the script is taking a while on the netbooks, then its the actual script that needs to be optimised and not copying the kix files across as obviously the script has already been "copied" across.


(KiX Supporter)
2014-01-13 09:25 AM
Re: Kix32.exe is too large, I use an old version.

 Originally Posted By: Robdutoit

I need to find a script that will allow me to calculate how long each line of code is taking to run.

Something to get you going. It requires the TimeDiff() UDF.

Break on

$start = @DATE + " " + @TIME
;Your code goes here
Sleep 6
$end = @DATE + " " + @TIME
?"Runtime = " + TimeDiff($start, $end, 'm', "1") + " minutes."

Sleep 5

(Hey THIS is FUN)
2014-01-13 07:32 PM
Re: Kix32.exe is too large, I use an old version.

I will have a look at that as well, although Glenn has kindly pointed out some code that I can use. Heaven knows when I will get around to testing it. When it rain it pours - and I am not talking about the weather at the moment, although it is chucking water down outside in England.

Glenn BarnasAdministrator
(KiX Supporter)
2014-01-13 07:59 PM
Re: Kix32.exe is too large, I use an old version.

Actually, the code I referenced is appropriate to log the time when a particular event in the script starts and/or finishes. Usually, it's assumed that a timestamp shows the completion of an event, the start time being the completion of the prior event. Of course, you can log the start and end if you want, particularly if you are logging specific function blocks and not every step along the way.

The TimeDiff that Mart pointed you to returns the difference between two timestamps, with ms accurracy. I would not use that for performance logging as there is much more overhead compared to the TimeStamp() UDF. It would be perfect, however, to use to determine precise differences between each of the values written to the perf log, probably by an analysis tool that read the perf log starting at line 2 and compared the time value with the prior line's time value. Something like
$aPerfData = FileIO('.\perflog.log', 'R')
For $P = 1 to UBound($aPerfData)
  $Time1 = Left($aPerfData[$P - 1], 23)  ; prior value
  $Time2 = Left($aPerfData[$P], 23)      ; current value
  $Diff = TimeDiff($Time1, $Time2, , 1)  ; difference w/ MS 
  $aPerfData[$P] = $aPerfData[$P] + ' - ' + $Diff + ' Seconds.'
$ = FileIO('.\perflog.log', 'W', $aPerfData)
This will calculate the difference between entries and write the different back to the file.