Doing a re-write of the KiX421Update.exe from MCA (again).
This is using the IExpress packager..
Done some distallation and consolidation of the code.. Also, trimmed down some of the long lines and removed uneeded parenthesis, spaces, etc.
However, when I run the update it generates the following in the Event Log as is directed by the script:
quote: Event Type: None Event Source: Kixtart UPDATE 4.21 Release Candidate 2c Event Category: None Event ID: 1 Date: 4/23/2003 Time: 8:31:25 AM User: N/A Computer: MACHINEID Description: The description for Event ID ( 1 ) in Source ( Kixtart UPDATE 4.21 Release Candidate 2c ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Kixtart-UPDATE 3.08 script completed successfully (08:31:25 - 08:31:25) (+kix421.ok +kix32.exe) to "c:\scripts\".
Now, if we look through this, we see that the code properly deploys KIX32.EXE and creates the Marker files .OK to the C:\ and to C:\Scripts to my NT-Classed system. Does this mean we can just simply ignore this?
Here is the modified INSTALL.KIX code:
code:
$prgrm_version='2.00' $sysdrv=SUBSTR('%WINDIR%',1,3) $destdir=$sysdrv+'Scripts' $message=Substr(@kix,1,1)+Substr(@kix,3,2) IF 0=EXIST($destdir) MD $destdir ELSE $destdir=$destdir+'\' ENDIF IF len($destdir)=0 $destdir=@lanroot+'\' ENDIF
quote: anyway, why you use files if you already log to the eventlog?
The .OK file is used for a marker to see if the deployment has occurred..
Maybe we should share our NTLOGON.BAT to show what is going on. This is using 4.02 at this point, but you get the idea:
code:
@Echo OFF
:: LAST EDITED; kld 07.01.02 @10:38PM pst :: Trimmed down to use less stuff.. :: - From: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q318689 (Modified)
VER | find "NT" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "2000" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "XP" > nul IF not errorlevel 1 GOTO Win_NT
VER | find "98" > nul IF not errorlevel 1 GOTO Win_9X
VER | find "95" > nul IF not errorlevel 1 GOTO Win_9X
GOTO unknown_os
:win_NT @TITLE Company NT Logon Script ECHO HELLO %USERNAME%! Echo Welcome to %USERDOMAIN%, Inc. NT Domain Environment ::if not exist %windir%\kix410.ok %LOGONSERVER%\NETLOGON\kix410update.exe /q ::if not exist %windir%\kix411.ok %LOGONSERVER%\NETLOGON\kix411update.exe /q if not exist %SystemDrive%\Scripts\nul md %SystemDrive%\Scripts if not exist %SystemDrive%\Scripts\kix402.ok %LOGONSERVER%\NETLOGON\Programs\kix402update.exe /q %SystemDrive%\Scripts\kix32.exe %LOGONSERVER%\NETLOGON\Kixtart.kix /f :: -- call is reserved for calling another batch file - BAD MICROSOFT!! ::%windir%\kix32.exe %LOGONSERVER%\NETLOGON\Kixtest.kix goto end
:win_9X :: --- CHECK FOR FILES TO SET THE USER NAME IF NOT EXIST %WINDIR%\PUTINENV.EXE XCOPY \\SERVER\NETLOGON\Programs\Win9x\PUTINENV.EXE %WINDIR% IF NOT EXIST %WINDIR%\WINSET.EXE XCOPY \\SERVER\NETLOGON\Programs\Win9x\WINSET.EXE %WINDIR%
:: --- SET THE Environment Variables :: -- Execute the script ::%WINDIR%\SYSTEM\KIX32.EXE %WINDIR%\SYSTEM\W95ENV.KIX
%WINDIR%\PUTINENV.EXE L %WINDIR%\winset computername=%COMPUTERNAME% %WINDIR%\winset username=%USERNAME% %WINDIR%\winset LANGROUP=%LANGROUP% %WINDIR%\winset LOGONSERVER=%LOGONSERVER%
:: --- DISPLAY THE USER NAME/DOMAIN ECHO HELLO %USERNAME%! ECHO Welcome to %LANGROUP%, Inc. Windows 9x Domain Environment
:: ********************************************************************************************** :: ******************************REMOVE FILES NOT NEEDED***************************************** :: ********************************************************************************************** ::if not exist %windir%\kix410.ok %0\..\kix410update.exe /q ::if not exist %windir%\kix411.ok %0\..\kix411update.exe /q if not exist c:\scripts\nul md c:\scripts if not exist c:\scripts\kix402.ok %0\..\Programs\kix402update.exe /q ::%0\..\kix.exe %0\..\kix32.exe %0\..\kix95.kix C:\scripts\kix32.exe %0\..\kixtest.kix goto end
:unknown_os :end
quote: I don't know why you would question the event log entry, your script deliberately puts it there.
I was concerned that a savvy user or Support Desk Tech would be a bit concerned with:
quote: The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer.
I should probably not worry myself so much with this. I was just trying to put together a cleaner roll-out of this.
Additionally, if we take this to the "next level."
If we are talking about KiXGolf scores: New install.kix 4,014 bytes
Original Install.kix 2,832 bytes Original Start1.kix 27,220 bytes Original Start2.kix 71,084 bytes ---- Total = 101,136
396.89% size increase. Yechh..
Some comments: (1) Why is START2.KIX in the archive if you are doing an automated install anyway? Yes, you can add switches, but if the code is solid enough, what is the point? (2) Why over-use parenthises? Is this to make this more "bullet-proof?" (4) Why not use variables? They cut down the length of lines and they can be re-used.
I haven't tried the code but from my first glance, I don't see WKiX32.exe being installed. Also, it appears to install KX95.dll without determining if it is required. I don't know if you are aware, but KX95.dll should NOT be installed unless the KXRPC service is installed. Having the DLL without the RPC service will cause problems. It's in the manual.
The usual purpose for parens is to force precedence. MCA tends to overuse them.
As a Moderator, I have seen the Manual. However, you bring up a good point with KX95.DLL. In this example, we are "installing" KIX32.EXE and not WKIX32.EXE to the client and not the server. This leads to the question, from the client, under WINTENDO, would you run XNET to query if the service is running on your DC?
Kent, Was not implying you have not read the manual, only that you may have overlooked that entry. I don't know why you would not install WKiX32.exe at the same time.
IMHO, I think that the installer should allow for parameters to exclude those components you do not want.
You will have to query all DCs for the service, as it would be sufficient to run the KXRPC service on only one DC and use redirection as described in the manual.
We had see your input already. We were just waiting on other reactions before we had the intention to return some input on your efforts. Possible, that we saw some interesting input.
Some elements in your versions show new ideas.
So we can make your script a little bit smaller when we are removing downward compatible requirements and when we doesn't need the debugging capabilities. Also we see some things which need some corrects.
Some remarks and suggestions:
we aren't using variables when we are referencing them only once. variables without any reference can be also comment f.e. $pgmvrs.
you are starting in the first WHILE/LOOP structure with the wrong $i value. it should be $i=1. it isn't your intention to copy an existing control file to your "X:\Scripts" location we suppose.
one of your last lines in second example $updinfo= is missing any goal. you aren't referencing them.
in the line IF Exist($destdir+$kixfl[0]) $destdir+$kixfl[0] ENDIF we are missing DELcommand.
we are missing the last three lines, which makes it possible to do some error checking from a batch job.
also you can replace the control file kix420.ok by registry entry, which makes your code also a little bit smaller. also it is possible that you are creating only one control file in the %windir% directory. the other location is only for backwards compatibility.
of course you need only one script to start installation, but in our version we have introduce both start1.kix and start2.kix versions to make it possible that we can help others with their problems by using our iexpress package.
of course the amount of information can reduced. for us it are only debugging issues. to claim a reducing with 396,89% isn't fair. without any debugging facility you must make the comparison with the start1.kix script only. with the above remarks included we can reduce your script into start1.kix 2.862 bytes (reducing 140.25%) or start1.kix 2.596 bytes (reducing 154.62%) or start1.kix 2.217 bytes (reducing 181.11%) Also you shouldn't forget that IEXPRESS compress those information too. More important is how much time both versions will cost during an installation process. With the UPCTimer 1.6 we get for our versions:
(1)why? when we are running it on our environment we doesn't need a debugging script liike start2.kix. more important is, that we can instruct people in an easy way to create debugging information about their iexpress installation when they have problems with it. Oh yeh, how did we solve the "terminal service" model? with a debug file.
(2)why over-use parenthises? indeed to make it more "bullet-proof" and to get a better layout in our opinion.
(3) ???
(4) why not use variables? in some situations it is possible, but we didn't. general people aren't see anything from our code. in some situations we are doing things twice to make reading not too hard. currently we are running our twenties version.
Reaction on the two Pennies of Les
indeed we are also missing the WKIX32.EXE. But it is important to know in which way Kent is creating his IEXPRESS package. It is f.e. possible that he is call WKIX32.EXE KIX32.EXE in his version.
sorry Les. Kent isn't installating DLL's when they aren't needed. He only verifies "do they exist and when positive remove them". Script contains only one COPY statement. See the first WHILE/LOOP structure.
Our version based on your second version
code:
DIM $max,$kixfl[$max+1] ; vs 3.10 $tmp=ExpandEnvironmentVars('%tmp%'+'\') $srcdir=@curdir+'\' $destdir=Substr('%WINDIR%',1,3)+'Scripts' $message=Substr(@kix,1,1)+Substr(@kix,3,2) ; IF Exist($destdir)=0 MD $destdir ENDIF IF Len($destdir)=0 $destdir=@lanroot ENDIF IF Substr($destdir,Len($destdir),1) <> '\' $destdir=$destdir+'\' ENDIF ; IF @inwin=1 $max=1 ELSE $max=4 ENDIF $kixfl[0]='kix'+$message+'.ok' $kixfl[1]='kix32.exe' $kixfl[2]='kx16.dll' $kixfl[3]='kx32.dll' $kixfl[4]='kx95.dll' $firstinst='yes' IF Exist($destdir+$kixfl[0]) $firstinst='no' ELSE DEL $destdir+'kix*.ok' ENDIF ; $updinfo='' $i=1 WHILE $i <= $max $srcfl=$srcdir+$kixfl[$i] $destfil=$destdir+$kixfl[$i] IF Exist($destfil) $rc=SetFileAttr($destfil,128) <> 0 ENDIF IF Exist($srcfl) IF GetFileSize($srcfl) <> GetFileSize($destfil) OR GetFileTime($srcfl) <> GetFileTime($destfil) OR GetFileVersion($srcfl,'filedescription') <> GetFileVersion($destfil,'filedescription') OR GetFileVersion($srcfl,'fileversion') <> GetFileVersion($destfil,'fileversion') OR GetFileVersion($srcfl,'internalname') <> GetFileVersion($destfil,'internalname') OR GetFileVersion($srcfl,'language') <> GetFileVersion($destfil,'language') OR GetFileVersion($srcfl,'originalfilename') <> GetFileVersion($destfil,'originalfilename') OR GetFileVersion($srcfl,'productname') <> GetFileVersion($destfil,'productname') COPY $srcfl $destfil /h $updinfo=$updinfo+' +'+$kixfl[$i] ELSE $updinfo=$updinfo+' ='+$kixfl[$i] ENDIF ENDIF $i=$i+1 LOOP ; $upok='yes' $i=1 WHILE $i <= $max $destfil=$destdir+$kixfl[$i] IF Exist($destfil) = 0 $upok='no' $updinfo=$updinfo+' unknown_file.'+$kixfl[$i] $rc=WriteProfileString($destdir+$kixfl[0],'KiX',$kixfl[$i],@date+' '+@time+' -> unknown file') ELSE $buildinfo=GetFileVersion($destfil,'specialbuild') IF Len($buildinfo) > 0 $buildinfo=' ('+Lcase($buildinfo)+')' ENDIF $rc=WriteProfileString($destdir+$kixfl[0],'KiX',$kixfl[$i],@date+' '+@time+' -> '+GetFileTime($destfil)+' '+GetFileSize($destfil)+$buildinfo) ENDIF $i=$i+1 IF @inwin=1 $i=$max+1 ENDIF LOOP $i=$max IF @inwin <> 1 $max=4 $i=2 WHILE $i <= $max $destfil=$destdir+$kixfl[$i] IF Exist($destfil) $rc=SetFileAttr($destfil,128) <> 0 DEL $destfil ENDIF $updinfo=$updinfo+' ?'+$kixfl[$i] $i=$i+1 LOOP ENDIF IF $upok='yes' $state='install complete at ' $info=$state+@date+' '+@time+' '+$updinfo ELSE $state='install incomplete at ' $info='update kix'+$message IF Exist($destdir+$kixfl[0]) DEL $destdir+$kixfl[0] ENDIF ENDIF $rc=WriteProfileString($dfl,'KiX','KiX release',@producttype+' -> kix '+@kix) $rc=WriteProfileString($dfl,'KiX','KiX',$info) ; IF Exist($destdir+'kix'+$message+'.ok') EXIT(0) ELSE EXIT(1) ENDIF
The reduced version
code:
dim $x1,$x2[$x1+1] $x3=ExpandEnvironmentVars('%tmp%'+'\') $x4=@curdir+'\' $x5=Substr('%WINDIR%',1,3)+'Scripts' $x6=Substr(@kix,1,1)+Substr(@kix,3,2) if Exist($x5)=0 md $x5 endif if Len($x5)=0 $x5=@lanroot endif if Substr($x5,Len($x5),1)<>'\' $x5=$x5+'\' endif if @inwin=1 $x1=1 else $x1=4 endif $x2[0]='kix'+$x6+'.ok' $x2[1]='kix32.exe' $x2[2]='kx16.dll' $x2[3]='kx32.dll' $x2[4]='kx95.dll' $x7='yes' if Exist($x5+$x2[0]) $x7='no' else del $x5+'kix*.ok' endif $x8='' $x9=1 while $x9<=$x1 $x10=$x4+$x2[$x9] $x11=$x5+$x2[$x9] if Exist($x11) $x12=SetFileAttr($x11,128)<>0 endif if Exist($x10) if GetFileSize($x10)<>GetFileSize($x11) OR GetFileTime($x10)<>GetFileTime($x11) OR GetFileVersion($x10,'filedescription')<>GetFileVersion($x11,'filedescription') OR GetFileVersion($x10,'fileversion')<>GetFileVersion($x11,'fileversion') OR GetFileVersion($x10,'internalname')<>GetFileVersion($x11,'internalname') OR GetFileVersion($x10,'language')<>GetFileVersion($x11,'language') OR GetFileVersion($x10,'originalfilename')<>GetFileVersion($x11,'originalfilename') OR GetFileVersion($x10,'productname')<>GetFileVersion($x11,'productname') copy $x10 $x11 /h $x8=$x8+' +'+$x2[$x9] else $x8=$x8+' ='+$x2[$x9] endif endif $x9=$x9+1 loop $x13='yes' $x9=1 while $x9<=$x1 $x11=$x5+$x2[$x9] if Exist($x11)=0 $x13='no' $x8=$x8+' unknown_file.'+$x2[$x9] $x12=WriteProfileString($x5+$x2[0],'KiX',$x2[$x9],@date+' '+@time+' -> unknown file') else $x14=GetFileVersion($x11,'specialbuild') if Len($x14)>0 $x14=' ('+Lcase($x14)+')' endif $x12=WriteProfileString($x5+$x2[0],'KiX',$x2[$x9],@date+' '+@time+' -> '+GetFileTime($x11)+' '+GetFileSize($x11)+$x14) endif $x9=$x9+1 if @inwin=1 $x9=$x1+1 endif loop $x9=$x1 if @inwin<>1 $x1=4 $x9=2 while $x9<=$x1 $x11=$x5+$x2[$x9] if Exist($x11) $x12=SetFileAttr($x11,128)<>0 del $x11 endif $x8=$x8+' ?'+$x2[$x9] $x9=$x9+1 loop endif if $x13='yes' $x15='install complete at ' $x16=$x15+@date+' '+@time+' '+$x8 else $x15='install incomplete at ' $x16='update kix'+$x6 if Exist($x5+$x2[0]) del $x5+$x2[0] endif endif $x12=WriteProfileString($x17,'KiX','KiX release',@producttype+' -> kix '+@kix) $x12=WriteProfileString($x17,'KiX','KiX',$x16) if Exist($x5+'kix'+$x6+'.ok') exit (0) else exit (1) endif
btw: another important issue was and is "we are using same scripts for different kixtart releases. also the kixtart 3.6x releases". So some new functions, commands or macros can't be used in our scripts.
Not trying to disuade you, but I would have to ask since I know you are quite busy at work and even doing work stuff at home. How important is this installer?
MCA already has it working (I assume)
Speaking for myself, I don't use any installer, never have. In fact I've now gone back to running it all from the NETLOGON folder again. Logons are quite fast and I have MUCH easier control of versions from this method.
Just curious why you're putting in so much effort on this.
mca, that last comment of yours you have said before.
but you have already deployment package for 3.xx
so, that argument is not true. you don't need to re-package those oldies with the new script. thus, you can write whatever you like in script, as far as the kix you are deploying supports it.
I was hoping that you would not take that way. I was/am not trying to pick on you or be unfair. The thought process was taking your current code and make it better (That is why we are here). If I didn't like this code, I would not have taken the initiative to start playing around with it. There may come a question, "shouldn't you leave it to the author?" Sure, if he has time!
If you take it as a challenge, that is very true. I was hoping that you would take this as constructive criticism.
To cite a couple of examples where I have solicited feedback for criticism - READEXCEL UDF SQLODBC UDF
As a result, I know that I have and probably will continue to publicly fall down, but I pick up and keep going.
IMHO, we should challenge ourselves or raise the bar each day. Maybe it is a strange philosophy of mine, but "how can we do it better?"
To respond to your comments:
quote: %windir% directory. the other location is only for backwards compatibility.
For what? Windows 3.x? Is there an OS that we have discussed that does not use this environment variable?
quote: of course the amount of information can reduced. for us it are only debugging issues. to claim a reducing with 396,89% isn't fair.
It was meant as humour. I know that we have a number of people that participate in the KiXGolf Challenges. The intent being, you take current code and squeeze it down without losing functionality.
quote: (2)why over-use parenthises? indeed to make it more "bullet-proof" and to get a better layout in our opinion.
If we can eliminate them, it looks and is more professional. Shouldn't this be a BKM or "Best Known Method?" This should be a practice that we as a community embrace! To quote one a post seen somewhat recently, "you should make your code accomodate the client, not client accomodate the code.
You have pointed out some variables that are not referenced. Isn't this supposed to be a "work in progress?" I think I can reciprocate that with you as well.
quote: btw: another important issue was and is "we are using same scripts for different kixtart releases. also the kixtart 3.6x releases". So some new functions, commands or macros can't be used in our scripts.
OK, that is nice, but why not going forward incorporate the new features?
This really begs the question, then.. Are you going back in and re-writing the code with the 3.6 version, for example and incorporating the Terminal Server (Drive M:) that we have talked about before? Or the DLLs that Les (if memory serves) brings up with Win 9x?
Shouldn't this be viewed in a positive manner? Take what is already there and make it better. Yes, the current versions and code do work.
quote: Not trying to disuade you, but I would have to ask since I know you are quite busy at work and even doing work stuff at home. How important is this installer?
MCA already has it working (I assume)
I would say that the installer makes it more convenient to run from the server and it updates the EXEs, runtime libraries, etc. on the client more easily.
quote: Speaking for myself, I don't use any installer, never have. In fact I've now gone back to running it all from the NETLOGON folder again. Logons are quite fast and I have MUCH easier control of versions from this method.
Just curious why you're putting in so much effort on this.
I have stated that we are going to the method too where we run all scripts from the server. If we need to update KIX32 or WKIX32, it is on the server and is much easier to control.
Back to your question - As we participate in the community, there will be a number of people out there for various reasons will want to distribute the files. This way we can provide alternatives than just simply copying them to the client.
Kent wasn't repeating us. His goal was that he can install the kixtart binaries into another directory ("c:\scripts")
Also it can be necessary that you must install kixtart on your clients. F.e. we are running all kind of scripts in the background without the requirement of a network connection. Also during logging on and with the speed of current networks such installation isn't necessary. During logging on we will always updating our kixtart binaries on the clients without using our control file to skip this element. Also such update isn't a big problem by modem connection.
Lonkero
Indeed we have said before, but sometimes the information must be complete.
Indeed we have already deployment package for 3.xx. When we are modifying our installation scripts in a significant way we update them all. Such moments were - when the control file was changing from format and location - when we were installing onlyt the required kixtart binaries on NTx environments - when we were restyling the way of creation and removing file associations Why? - the way it works is the same for all versions. so we will not get questions "why doesn't work that capability on our version" and "can you implement them also in this older kixtart version". - debugging is much easier when we are using the same scripts in all packages. output should look always the same. - helping people is also much easier and not only for us.
Of course it is possible that we are using the new features of kixtart in this process, but it hasn't any priority for us. Packages work at the moment and new one can be created automatically. Simply one mouse click in our situation. Also the amount of required time for running is also very acceptable.
kdyer
Kent, we were just joking a little bit about the reduction factors. Just during the analyse of your version we see some nice things and also we see why we can't implement them all at this moment. The same script should run also on oldest kixtart package release. Also we know that your goal was to reduce our code a little bit and we want to give your other ideas about further reduction. For other (new) members we show that they can reduce their scripts also without modifying them before.
Once we were using two significant different versions of "kixstrip", which was very hard to maintain.
About backwards compatibility: when people where using an earlier version of our packages during deployment we must cleanup the mess from those earlier versions. when people where using only latest versions of our packages it isn't necessary to do that. In our script above we doesn't use "c:\kix???.ok" at all. We have to deal only with the "%windir%\kix???.ok" control file. For people using the old format of deployment we create also the second control file "c:\kix???.ok". The old format is meaning here
code:
if not exist c:\kix420.ok %0\..\kix420update /q
The new format is
code:
if not exist %windir%\kix420.ok %0\..\kix420update /q
Kent, we like your humour. Only we must prevent that other people without internal knowledge of those scripts think "why so much bytes necessary". We suggest that people are keeping always the original source. Original source contains f.e. comment. An reduced version can be hard to maintain. We don't think, that you of anybody else love it to modify our reduced version with variable names like $x1, $x2, ...., $x35.
About parenthises some language makes it possible that you are using short versions of available keywords. of course typing the short ones doesn't cost much time, but reading those code many years later make it very hard to understand what it means and to maintain. Using parenthises makes in our opinion code much easier to read. Something similar with "specifying default results" and "layout of structures" and "not using GOTO's". Using a good indentations makes it very easy to find back the position where to insert f.e. the missing ENDIF in your script. No indentations is exactly the opposite of it. Some elements for good programming in our opinion is: - other people can easily read what it is doing without the requirement of have depth knowledge of that language. - other people can modify code in an easy way for their own purposals. - other people can easy maintain code or implement new functionality. and that they don't write a complete new version of your script and that they don't throw away your version because modifying is too hard for them.
About variables without reference we only mention them. We know you are working still on a final version. Sometimes we publish different versions of our scripts and tools in a very short time, when we need to incorporate member's feedback.
About going back ... with the 3.6 version everything is incorporate in same script. So we aren't going back. Not only in the recent kixtart releases people want to have the capability of installation only the required kixtart binaries. Also an implementation by using another SYSTEM DRIVE is a very good extension. More about it you have already read.
Kent, we appreciate always your input and feedback. When our feedback shows a negative manner it wasn't our goal. Apology for that. Possible we were choosing the wrong words, but we never mean that.
We agree with you that we also implement stuff for a number of people. For our situations many things weren't implemented at all. Kent, do you know how many questions the MM-club guys put on this board? We think not so much. Most of their input is for helping others.
quote: About backwards compatibility: when people where using an earlier version of our packages during deployment we must cleanup the mess from those earlier versions. when people where using only latest versions of our packages it isn't necessary to do that. In our script above we doesn't use "c:\kix???.ok" at all. We have to deal only with the "%windir%\kix???.ok" control file.
So, you are trying to make a "one size fits all" solution? There are times where the person cannot upgrade KiXtart..
In testing with a "locked down" user, we could not write to %windir%..
quote: We don't think, that you of anybody else love it to modify our reduced version with variable names like $x1, $x2, ...., $x35.
In coding, I try to keep some meaning to variable names, just shorten them.
quote: About parenthises some language makes it possible that you are using short versions of available keywords. of course typing the short ones doesn't cost much time, but reading those code many years later make it very hard to understand what it means and to maintain.
Hard to maintain? For who? If you have mal-formed syntax, then yes I could see your point. It makes it really difficult for you to have one standard and everybody else have quite another. Does it mean that the code works better? I would argue against that with an emphatic NO!!
Let's take for example the following code:
code:
IF (0=INGROUP("GROUP")) ;DO STUFF ENDIF
It is much better to do:
code:
IF 0=INGROUP("GROUP") ;DO STUFF ENDIF
If we think about this from a processing perspective, if these can be reduced, login time for example, is reduced. We all have to deal with people complain about login times anyway. If we can shave these off, even a few seconds, the better!
As another argument here, with the newer versions of KiXtart, Ruud has been kind enough to implement internal error control and displaying the error and the line number the error is coming from.
code:
About going back ... with the 3.6 version everything is incorporate in same script.
Why? Portability maybe a fair argument.. However, if you we look at the $os variable you use, why not use the Macro @PRODUCTTYPE instead with the new versions. I hate to pull other people into this discussion, but if Jochen/Jooel stayed with their original code with PostPrep/BBChecker, would it still work? Sure, these products work in their beginning versions, but they improved on it. Hence, they made it better!! Can't you/we do the same for KiXnnnUpdate.EXE program?
This process this should be a experience of how we do our practices better!!
Regards,
Kent
[ 30. April 2003, 15:07: Message edited by: kdyer ]
kix deployment in UDF? well, why not... don't think so though as this is based on the idea of being executable easy to use and small as possible... don't think so.
Yea, but if you put it in a UDF you make it easy to find & use by inexperienced persons. It could return various status codes indicating what it did. Like other UDFs it would be an off the shelf tool that users could use at their discretion. My guess it is would get a fair amount of takers, especially with new kix programmers.
In my opinion, making it a UDF doesn't preclude it being tightly coded or it being easy to use.
quote:UDF you make it easy to find & use by inexperienced persons
'UDF' and 'inexperienced persons' when used in the same sentence is an oxymoron.
Purists may argue that it is not right to make a UDF out of it. Basicaly, it is the source code that gets packaged up as an EXE, not something that 'inexperienced persons' would undertake.
With all the recent changes to kixtart an update function is almost mandatory if you wish to fully exploit kixtart. Possibly due to this fact, I have noticed a lot of newbee script postings to this site tend to have embedded in them a kix32.exe update function. Sometimes they embed it in the command script & other times in the kix script but it is there more times then it isn’t.
Given this point, why not provide these programmers with a UDF that does this properly. Putting this script in the Scripts forum is not an effective distribution mechanism in my opinion.
What I was thinking is that it appears that more & more of the visitors to this site are using the UDfs to tackle some very complex problems & the kix32.exe update UDF would just be another tool for them to pick up. I believe it could help a lot of less experienced kix programmers.
As a side point, perhaps your definition of “inexperienced” & mine are different. I was thinking of an experienced LAN administrator without much kix experience.
Kent, reducing a script with variable names like $x1, $x2, ..., $x35. Isn't good programming at all, but when a script goes in production it isn't relevant what layout that script will get. At least the original script including comment and right indentation is your source for edit operations.
A good issue is "kixtart has an internal error control capabilities", which will be gone when we combine different lines input one very long line. Of course it is possible, that you reduce your scripts by removing unwanted comment, spaces and 'print'-statements. Just use as kixstrip call
I think we need to look at the top section of this script.. It should be an array..
Please note the comments in code.
code:
DIM $a,$kxfl $tmp=ExpandEnvironmentVars('%tmp%\') $srcdir=@curdir+'\' $destdir=Substr('%WINDIR%',1,3)+'Scripts\' $message=JOIN(split(@kix,'.'),'')
IF 0=Exist($destdir) MD $destdir ENDIF
IF @inwin=1 $a='kix32.exe', 'wkix32.exe' FOR EACH $kixfl IN $a COPYKIX($kixfl) NEXT ELSE $a='kix32.exe', 'wkix32.exe', 'kx16.dll', 'kx32.dll', 'kx95.dll' FOR EACH $kixfl IN $a COPYKIX($kixfl) NEXT ENDIF
FUNCTION COPYKIX($file) $srcfl=$srcdir+$file $destfil=$destdir+$file IF Exist($destfil) $rc=SetFileAttr($destfil,128)<>0 ENDIF IF Exist($srcfl) IF GetFileSize($srcfl) <> GetFileSize($destfil) OR GetFileTime($srcfl) <> GetFileTime($destfil) OR GetFileVersion($srcfl,'fileversion') <> GetFileVersion($destfil,'fileversion') COPY $srcfl $destfil /h ENDIF ENDIF ENDFUNCTION
$rc=ADDKEY('HKCU\Software\KiXtart') IF READVALUE('HKCU\Software\KiXtart','KIXPKG')<>'kix'+$message $rc=WRITEVALUE('HKCU\Software\KiXtart','KIXPKG','kix'+$message,'REG_SZ') ELSE EXIT 1 ENDIF
The .ok provides a convenient "marker" to look for in the NTLOGON.BAT file. While this information can be written/read to the registry, it cannot be read or picked up without an external tool...
it is anyway more trustworthy to run the checking every time.
thus packaging this with kixtart as self-executable... although that makes the logon start little slower (exe size would be approx 150k) it would always be for sure.
but, if the ok is trusted, there must be something else there than just checking the file-name and it's location... modification time and it's incredients or something needs to match too to be trustable.
FUNCTION COPYKIX($srcfile,$destfile) dim $ IF Exist($srcfile) IF Exist($destfile) $=SetFileAttr($destfile,128) ENDIF IF GetFileSize($srcfile) <> GetFileSize($destfile) OR GetFileTime($srcfile) <> GetFileTime($destfile) OR GetFileVersion($srcfile) <> GetFileVersion($destfile) COPY $srcfile $destfile /h ENDIF ENDIF ENDFUNCTION
[ 02. May 2003, 12:21: Message edited by: Lonkero ]
As I stated earlier, "we" as a company are looking at the possibility of going away from this. That is, remembering that this exercise is for people that cannot.
Now, we need to make the OK or marker file more "bullet-proof."
That way, when you run the NTLOGON.BAT, it will find it..
Portion of the NTLOGON.BAT
code:
if not exist %SystemDrive%\Scripts\kix421.ok %LOGONSERVER%\NETLOGON\Programs\kix421update.exe /q
Here is the code..
code:
DIM $FilesToCopy,$ $tmp='%tmp%\' $srcdir=@scriptdir+'\' $destdir=split('%WINDIR%',':')[0]+':\Scripts\' $msg=LEFT(JOIN(split(@kix,'.'),''),3) $ok=$destdir+'kix'+$msg+'.ok'
IF 0=Exist($destdir) MD $destdir ENDIF
$FilesToCopy='kix32.exe wkix32.exe' IF @inwin=2 $FilesToCopy=$FilesToCopy+' kx16.dll kx32.dll kx95.dll' ENDIF
FOR EACH $ IN Split($FilesToCopy) COPYKIX($srcdir+$,$destdir+$) NEXT
FUNCTION COPYKIX($srcfile,$destfile) dim $ IF Exist($srcfile) IF Exist($destfile) $=SetFileAttr($destfile,128) $state=' >replaced' ELSE $state=' >new' ENDIF IF GetFileSize($srcfile)<>GetFileSize($destfile) OR GetFileTime($srcfile)<>GetFileTime($destfile) OR GetFileVersion($srcfile)<>GetFileVersion($destfile) IF EXIST($destdir+'kix*.ok') Del $destdir+'kix*.ok' ENDIF COPY $srcfile $destfile /h $=WRITEPROFILESTRING($ok,split(split($destfile,'\')[2],'.')[0],'KIX',$destfile+$state) ENDIF ENDIF ENDFUNCTION
Wow, Joeel, jeez, I though my monitor is about to explode. What's up with that yellow color Don't surprise an old man like me with this on a Sunday morning!
way of using registry is indeed a good alternative. We see three possible problems - the HKCU-hive isn't available by W9x logging on. An alternative can be that you put those informative to the HKLM hive. - by using mandatory profiles the registry information we will gone during each logging on. So each time the installation package will reinstall itself on the client with the necessary to do it. - with the general DOS commands you can't check the registry content.
about IF Len($destdir)=0 $destdir=@lanroot ENDIF has to deal with the possibility that the environment variable %windir% doesn't exist. Normally it is not a problem, but we have to deal with all kind of possibilities.
with the current network speed and with the required execution times of iexpress package runs it isn't necessary to check each time you control file kix???.ok. Also for a modem connection it is acceptable.
for testing the control-file in a DOS environment we are restricting to the available DOS commands. f.e. it's size isn't such function.
we are missing the part of removing unwanted kixtart binaries, when they were implemented with an older edition of iexpress packages. Specially when the current location isn't the same as previous locations. f.e. c:\scripts\kix32.exe c:\scripts\kx16.dll c:\scripts\kx32.dll c:\scripts\kx95.dll c:\windows\kix32.exe c:\windows\kx16.dll c:\windows\kx32.dll c:\windows\kx95.dll Do you know which version it will use, when this will be the result. So removing them can be necessary to prevent unexpected errors during using kixtart.
The reduction effort of different guys contains all kind of interesting elements. greetings.
we can make perfect checks with FC but how to check so trustfully...
anyway, the deletion of old files indeed is a thing we need to check... maybe also that on failure of deletion of some file, we also get problems...
then, nowadays as ppl are finally (others than me) getting rid of logon.bat... is there still a need to distribute the executable? over ras it's slow to run logon-from network but with even slow 256kb connection it's already quick enough to not need a dist...
In an earlier post of us in this topic you can read
quote: Also it can be necessary that you must install kixtart on your clients. F.e. we are running all kind of scripts in the background without the requirement of a network connection. Also during logging on and with the speed of current networks such installation isn't necessary. During logging on we will always updating our kixtart binaries on the clients without using our control file to skip this element. Also such update isn't a big problem by modem connection.
In our opinion FC isn't a good way of comparison, which has to deal with the control file. Our version of control file is changing all the time based on type of windows and the time of installation.
When you have problem with the deletion of old file it will be good to include those information also in f.e. control file. A control file which can be located on the server too. greetings.
quote: An alternative can be that you put those informative to the HKLM hive.
If you have a "locked down" user, would this still be available?
quote: has to deal with the possibility that the environment variable %windir% doesn't exist.
Where in the world is this coming from? In time that we have been doing Computer Support (going on 8+ years now). This has never been true.. The only exception would be if you as the Technician were tweaking with the PATH. Why? Almost all programs out there need to know where WINDOWS is located. OK.. 16-Bit Apps? Sure, they need to know where to find WOWEXEC and NTVDM too.. Or, even %WINDIR%\command..
quote: c:\scripts\kix32.exe ..other files..
In testing with various users on our domain, we decided to go with a folder outside of %WINDIR% as we had trouble copying a file there.
To Lonkero..
quote: it's slow to run logon-from network but with even slow 256kb connection it's already quick enough to not need a dist...
We are starting to investigate this too. We are seeing some pretty dramatic results. You are 100% correct, you don't have to create distro package either.
Back to MCA..
quote: When you have problem with the deletion of old file it will be good to include those information also in f.e. control file. A control file which can be located on the server too.
So.. Then, why not include this in the login log for the client.. You could check a database, currently we use a rather large text file (yes, a performance hit). But an Access or SQL Database, you could not only write the client login info, but KIX too. But, then again, if you keep the Executable and script on the server, is this needed? Sure, this is grand exercise for people that have not decided or cannot make this type of transistion.
CLS BREAK ON $DomainString='DOMAIN' ;Replace with your domain $GroupString='Domain Users' $GroupObj = GetObject('WinNT://' + $DomainString + '/' + $GroupString) For each $UserObj in $GroupObj.Members ;Look for the word NTLOGON in case of NTLOGON OR NTLOGON.BAT IF $UserObj.AccountDisabled<>'True' AND INSTR($UserObj.LoginScript,'NTLOGON') ?$UserObj.Name ?$UserObj.FullName $UserObj.LoginScript = 'WKIX32.EXE' $UserObj.SetInfo $error=@error $logshare='H:\' ;Change to an available drive or UNC path $logfile=$logshare+$DomainString+'CHANGESCRIPT.CSV' $logdata=$UserObj.Name+','+$UserObj.FullName+','+$error+@CRLF LOGGER($logfile,$logdata)
ENDIF Next ?'--' ?'Script complete' SLEEP 4
FUNCTION LOGGER($logfile,$logdata) DIM $n WHILE Open(1, $logfile, 5) OR $n=5 IF $n '.' ELSE ?'Please wait' ENDIF $n=$n+1 SLEEP 3 LOOP $n=WriteLine(1, $logdata) $n=Close(1) ENDFUNCTION
I was also thinking about it... if I don't remember wrong, it also checks for kixtart.scr (might have changed in last versions, last checked somewhere around the time of 3.5x-3.6x)
but the user is anyway logged on and if your script (like mine) has not console-window, the user has no clue that actually when his MSN is logging on, also logonscript is running
if not exist %SystemDrive%\Scripts\kix402.ok %LOGONSERVER%\NETLOGON\Programs\kix402update.exe /q %SystemDrive%\Scripts\kix32.exe %LOGONSERVER%\NETLOGON\Kixtart.kix /f GOTO END
The problem is that if KIX402.OK (it should not matter what version) is not on the client system, it spawns two login scripts. This is because we are using KIXTART.KIX on both of our domains and when the "Applaunched" is done from IEXpress, it looks for KIXTART.KIX and starts it as well as the NTLOGON.BAT. I have talked with our Management team about converting the user profiles to use WKIX32 in place of NTLOGON and they are pretty content to leave it as is.
I have tried to do the following in the NTLOGON.BAT File in an attempt to remedy this -
code:
if not exist %SystemDrive%\Scripts\kix402.ok %LOGONSERVER%\NETLOGON\Programs\kix402update.exe /q && GOTO END %SystemDrive%\Scripts\kix32.exe %LOGONSERVER%\NETLOGON\Kixtart.kix /f GOTO END
The problem now is when you add && GOTO END, the script does not start then.
if not exist %SystemDrive%\Scripts\kix402.ok %LOGONSERVER%\NETLOGON\Programs\kix402update.exe /q CALL %SystemDrive%\Scripts\kix32.exe %LOGONSERVER%\NETLOGON\Kixtart.kix /f
Made the following changes to the INSTALL.KIX file: