#74723 - 2003-04-29 02:54 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
MCA,
Ahh.. Some feedback...
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. ![[Smile]](images/icons/smile.gif)
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.
Kind Regards,
Kent
|
|
Top
|
|
|
|
#74724 - 2003-04-29 04:29 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Doc,
I will respond..
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.
Thanks,
Kent
|
|
Top
|
|
|
|
#74725 - 2003-04-30 07:16 AM
Re: Re-Write of the KIX32.EXE Deployment tool
|
MCA
KiX Supporter
Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
|
Dear,
NTDOC
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.
Kent, keep on going.
greetings.
[ 02. May 2003, 04:10: Message edited by: MCA ]
|
|
Top
|
|
|
|
#74726 - 2003-04-30 03:06 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
MCA,
Responding to your points to me.
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 ]
|
|
Top
|
|
|
|
#74732 - 2003-05-01 05:23 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Getting the following message:
quote:
ERROR : array reference out of bounds!
Script: C:\!Kix\newpkg\install.KIX
Line : 21
Line 21 is >> $kixfl[2]='kx16.dll'
Here is the code at this point:
code:
DIM $max,$kixfl[$max+1] ; vs 3.10
$tmp=ExpandEnvironmentVars('%tmp%\')
$srcdir=@curdir+'\'
$destdir=Substr('%WINDIR%',1,3)+'Scripts\'
$msg=join(split(@kix,'.'),'')
IF Exist($destdir)=0
MD $destdir
ENDIF
IF Len($destdir)=0
$destdir=@lanroot
ENDIF
IF @inwin=1
$max=2
ELSE
$max=5
ENDIF
$kixfl[0]='kix'+$msg+'.ok'
$kixfl[1]='kix32.exe'
$kixfl[2]='wkix32.exe'
$kixfl[3]='kx16.dll'
$kixfl[4]='kx32.dll'
$kixfl[5]='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
IF @ERROR=0
$upok='yes'
ELSE
$upok='no'
ENDIF
$updinfo=$updinfo+' +'+$kixfl[$i]
ELSE
$updinfo=$updinfo+' ='+$kixfl[$i]
ENDIF
ENDIF
$i=$i+1
LOOP
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'+$msg+'.ok')
EXIT(0)
ELSE
EXIT(1)
ENDIF
Thanks,
Kent
|
|
Top
|
|
|
|
|
#74734 - 2003-05-01 07:39 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
OK..
Think we have it..
Ladies and Gentlemen, here it is!
This is no to say that it cannot be improved upon. ![[Razz]](images/icons/tongue.gif)
code:
CLS
BREAK ON
DIM $max ; vs 3.10
$tmp=ExpandEnvironmentVars('%tmp%\')
$srcdir=@CURDIR+'\'
$destdir=Substr('%WINDIR%',1,3)+'Scripts\'
$msg=JOIN(split(@KIX,'.'),'')
IF Exist($destdir)=0
MD $destdir
ENDIF
IF Len($destdir)=0
$destdir=@lanroot
ENDIF
IF @inwin=1
$max='2'
ELSE
$max='5'
ENDIF
REDIM $kixfl[$max+1]
$kixfl[0]='kix'+$msg+'.ok'
$kixfl[1]='kix32.exe'
$kixfl[2]='wkix32.exe'
$kixfl[3]='kx16.dll'
$kixfl[4]='kx32.dll'
$kixfl[5]='kx95.dll'
$firstinst='yes'
IF Exist($destdir+$kixfl[0])
$firstinst='no'
ELSE
DEL $destdir+'kix*.ok'
ENDIF
$dfl=$destdir+$kixfl[0]
IF SUBSTR($kixfl[0],4,3) = LEFT(JOIN(split(GETFILEVERSION('KIX32.EXE'),', '),''),3)
EXIT(0)
ELSE
$rc=WriteProfileString($dfl,'KiX','KiX release',@PRODUCTTYPE+' -> kix '+@KIX)
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
IF @error=0
$upok='yes'
$state='install complete at '
$info=$state+@date+' '+@time+' '+$updinfo
ELSE
$upok='no'
$state='install incomplete at '
$info='update kix'+$message
ENDIF
$updinfo=$updinfo+' +'+$kixfl[$i]
ELSE
$updinfo=$updinfo+' ='+$kixfl[$i]
ENDIF
ENDIF
$i=$i+1
$rc=WriteProfileString($destfil,'KiX','KiX',$info)
LOOP
IF Exist($destdir+'kix'+$msg+'.ok')
EXIT(1)
ELSE
EXIT(2)
ENDIF
ENDIF
Thanks,
Kent
|
|
Top
|
|
|
|
|
#74737 - 2003-05-01 10:32 PM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Jack,
I mentioned that this could use some improvement.
Anyway, I am getting -
quote:
ERROR : invalid method/function call: missing ')'!
Script: C:\!Kix\newpkg\install.KIX
Line : 31
code:
CLS
BREAK ON
DIM $max
$tmp=ExpandEnvironmentVars('%tmp%\')
$srcdir=@CURDIR+'\'
$destdir=Substr('%WINDIR%',1,3)+'Scripts\'
$msg=JOIN(split(@KIX,'.'),'')
IF Exist($destdir)=0
MD $destdir
ENDIF
IF Len($destdir)=0
$destdir=@lanroot
ENDIF
IF @inwin=1
$max=2
REDIM $kixfl[$max+1]
$kixfl[0]='kix'+$msg+'.ok'
$kixfl[1]='kix32.exe'
$kixfl[2]='wkix32.exe'
ELSE
$max=5
REDIM $kixfl[$max+1]
$kixfl[0]='kix'+$msg+'.ok'
$kixfl[1]='kix32.exe'
$kixfl[2]='wkix32.exe'
$kixfl[3]='kx16.dll'
$kixfl[4]='kx32.dll'
$kixfl[5]='kx95.dll'
ENDIF
$firstinst='yes'
IF Exist($destdir+$kixfl[0])
$firstinst='no'
ELSE
DEL $destdir+'kix*.ok'
ENDIF
$dfl=$destdir+$kixfl[0]
IF SUBSTR($kixfl[0],4,3)=LEFT(JOIN(split(GETFILEVERSION('KIX32.EXE'),', '),''),3)
EXIT 0
ELSE
$rc=WriteProfileString($dfl,'KiX','KiX release',@PRODUCTTYPE+' -> kix '+@KIX)
$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
IF @error=0
$upok='yes'
$state='install complete at '
$info=$state+@date+' '+@time+' '+$updinfo
ELSE
$upok='no'
$state='install incomplete at '
$info='update kix'+$message
ENDIF
$updinfo=$updinfo+' +'+$kixfl[$i]
ELSE
$updinfo=$updinfo+' ='+$kixfl[$i]
ENDIF
ENDIF
$i=$i+1
$rc=WriteProfileString($dfl,'KiX','KiX',$info)
LOOP
IF Exist($destdir+'kix'+$msg+'.ok')
EXIT 1
ELSE
EXIT 2
ENDIF
ENDIF
Thanks,
Kent
|
|
Top
|
|
|
|
|
#74738 - 2003-05-02 04:20 AM
Re: Re-Write of the KIX32.EXE Deployment tool
|
MCA
KiX Supporter
Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
|
Dear,
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
code:
kixstrip input.kix output.kix /nocombine /noheaders /nolicense
The result with our input can be
code:
DIM $max,$kixfl[$max+1]
$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 other suggestion about upgrading $os is also a good suggestion. Such
implementation is indeed possible. We put it also on our TO-DO list.
The result looks great. Bravo.
greetings.
(TO_DO: kixstip + "$os" + put some ideas in our version)
|
|
Top
|
|
|
|
#74739 - 2003-05-02 06:06 AM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
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
Thanks,
Kent
[ 02. May 2003, 08:10: Message edited by: kdyer ]
|
|
Top
|
|
|
|
|
#74741 - 2003-05-02 06:39 AM
Re: Re-Write of the KIX32.EXE Deployment tool
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Rather than littering the drive with marker files.. removed it and use a registry check..
Kent
|
|
Top
|
|
|
|
Moderator: Glenn Barnas, NTDOC, Arend_, Jochen, Radimus, Allen, ShaneEP, Ruud van Velsen, Mart
|
0 registered
and 980 anonymous users online.
|
|
|
![[Frown]](images/icons/frown.gif){kind=icon}
![[Confused]](images/icons/confused.gif){kind=icon}
![[Big Grin]](images/icons/grin.gif){kind=icon}
