#208269 - 2014-01-07 08:52 PM
Kix32.exe is too large, I use an old version.
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
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: http://www.kixhelp.com/hb/
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!
Edited by Lonkero (2014-01-14 04:32 AM)
Edit Reason: the original thread was last replied to10 years ago and not deeply enough related to warrant unburying the dead. http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=128905&fpart=1
|
|
Top
|
|
|
|
#208270 - 2014-01-07 09:14 PM
Re: Kix32.exe is too large, I use an old version.
[Re: Robdutoit]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
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.
Glenn
PS - Grave robbing is right! I think that 10 years is the record for necro'ing a thread! 
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
|
#208308 - 2014-01-13 07:59 PM
Re: Kix32.exe is too large, I use an old version.
[Re: Robdutoit]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4396
Loc: New Jersey
|
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.'
Next
$ = FileIO('.\perflog.log', 'W', $aPerfData)
Glenn
_________________________
Actually I am a Rocket Scientist!
|
|
Top
|
|
|
|
Moderator: Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 370 anonymous users online.
|
|
|
