| ciper |
| (Fresh Scripter) |
| 2004-11-03 01:11 AM |
Kix32.exe is too large, I use an old version...
|
Not sure I understand the continual increase in size of the KIX executable over time. Are the developers getting lazy on optimization?
The older version Ive been using is 61k, one quarter the size of the current version.
On top of that, using an executable compression application like UPX ( http://upx.sourceforge.net/ GNU GPL) will give me a file size of under 100kb on the current version and 21k on the older version I have!!!
Before you start to ask, when you have well over 1000 machines at a single site (with sites all over the world) the difference between the two versions I mention is about 200 megabytes of extra traffic the domain controllers have to deal with every morning.
So what gives?
Shawn
|
| (KiX Supporter) |
| 2004-11-03 01:21 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
You think size matters eh ? ;0)
Just did a quick enum of Kixtart over the years ...
2.33 = 80kb
3.63 = 163kb
4.00 = 196kb
4.22 = 241kb
So what version were you running ? Given the number of features added over the years, and the big swing with COM starting with 4.00, don't think a 241kb scripting language is large at all ... 241kb is tiny (relatively speaking imho).
| ciper |
| (Fresh Scripter) |
| 2004-11-03 01:35 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
How I see it is you have a base set of code that takes most of the file size then additional code for those added features. If the current version is 4 times the size of version 3.21 shouldnt have at least 5-6 times the features?
When I do a kix32 /? on the version Im using it reports:
>>> KiXtart 95 3.21
Windows NT 3.x / Windows 95 logon script processor and/or registry editor.
Usage : KIX32 [script1] [...] [$var=123]
File size is 61kb
You may think 241 is relatively small when thinking of transfering this file once. Try transfering it thousands of times along with the other files used during your login (registry settings, policy files, scripts themselves) and the burden on the servers becomes noticable.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 01:41 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
We usually do a one-time copy of kix32.exe to the workstation first, thats gets it on the workstation then from there on in, its faster than stink ... plus dont forget, two other features were added that aren't so "in-your-face" noticable, most notibly:
Group Caching
Tokenized Scripts
Both these new features makes Kixtart the logon scripting language of choice ... if your concerned with size versus features versus performance, suggest you stick with BAT files for your scripts ... you know the old saying as well as I do, no such thing as a free lunch.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 01:51 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
I'll tell what I think Kixtart does have ... lots of baggage ... baggage from supporting the Win9x systems. Because there was so much stuff originally embedded into Kixtart to support working 9x in the NT domain ... tons of baggage me thinks.
But Ruud always provided backward compatibility, and we all know that comes with a price too.
| Les |
| (KiX Master) |
| 2004-11-03 01:56 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
I use an old version
Good for you. So then why are you complaining? You want the features of the latest version but don't want to pay for it?
You are obsessing over size. 200k is peanuts related to what else goes up and down the pipe. Like Shawn said, copy it to the client if you are so concerned.
I have single spreadsheets that add up to more that what your DC transfers in an entire day and I am not obsessing.
| ciper |
| (Fresh Scripter) |
| 2004-11-03 02:12 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Copying to the client is possible, I could add something like
%systemroot%\system32\FC.exe %temp%\KIX32.EXE %0\..\KIX32.EXE /LB1 > NUL
if %errorlevel% == 1 GOTO KIXDIF ;different than DC
if %errorlevel% == 2 GOTO KIXDIF ;not found
echo kix is the same >> "%temp%\loginsteps.txt"
goto KIXSAME
:KIXDIF
echo kix is dif >> "%temp%\loginsteps.txt"
copy /Y %0\..\KIX32.EXE %temp% > NUL
:KIXSAME
That way I have version control in case it changes...
| ciper |
| (Fresh Scripter) |
| 2004-11-03 02:26 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
Quote:
I use an old version
Good for you. So then why are you complaining? You want the features of the latest version but don't want to pay for it?
You are obsessing over size. 200k is peanuts related to what else goes up and down the pipe. Like Shawn said, copy it to the client if you are so concerned.
I have single spreadsheets that add up to more that what your DC transfers in an entire day and I am not obsessing.
Sounds like both of you live by the idea that if you have extra bandwith you might as well use it.
Why no interest in optimization? If I can grab a executable compression application found on google in 5 seconds and reduce the file size by 60% that leads me to believe more could be done in development.
All of this adds up to the time the user spends waiting for his machine. In the end 5 seconds here and there may not sound like much but if you can reduce the wait time 15 seconds overall (trying to optimize in any way you can) and multiply that by the number of employees, the number of work days and the average salary you just saved a good chunk of change!
Oh and to give you an idea quickly, I do have extremely fat pipes to the machines on the network. Ill share with you because Im proud of it
Users are connected to a group of Cisco 4507 in every area with dual sup and 5 ws-x4548-gb cards. Thats 10/100/1000 to the desktop (and many machines have gigabit nics). Those are dual fiber attached to two 6513. The servers are dual connected to ws-6748-ge in the 6513s which have sup 720s, dual copper load balanced GB connections to most of the servers.
I understand that additional features need an increase in file size. What I cant see is such a large increase that relate to a few useful features and a few more less often used features.
I propose not only getting the main kix32 executable file size smaller in some way but also the possibility of a "light" version geared towards the most common used commands!
| ciper |
| (Fresh Scripter) |
| 2004-11-03 02:44 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
UPX output
C:\temp>upx --best -v kix32.exe
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
UPX 1.25d Markus F.X.J. Oberhumer & Laszlo Molnar Jun 29th 2004
File size ---------- Ratio---- Format --- Name
-------------------- ------ ----------- -----------
241664 -> 99328 41.10% win32/pe kix32.exe
Packed 1 file.
| Les |
| (KiX Master) |
| 2004-11-03 03:29 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
I propose not only getting the main kix32 executable file size smaller in some way but also the possibility of a "light" version geared towards the most common used commands!
I don't agree with a stripped down version that has only a subset of commands and functions. I do agree though that the EXE could be made smaller and posted the following suggestion a while back.
MakeEXE for KiX 4.5
BTW, your batch file with FC.EXE would not lessen the network traffic since the bytes needed for a file compare is the same as if you just ran it from the DC. The way some people manage versioning is to calculate and store the CRC of the seed copy and then check the CRC on just the local copy.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 03:40 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
Maybe I've just been spoiled the past few years, haven't used dialup access since my old VAX days, but over one of these "slow" links, what kinda saving are we talking about here ?
A file that is 100kb versus one that is 250kb ... what would be the savings in terms of speed here ? 1 second ? 10 seconds ? 60 seconds ?
-Shawn
| ciper |
| (Fresh Scripter) |
| 2004-11-03 03:56 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
"BTW, your batch file with FC.EXE would not lessen the network traffic since the bytes needed for a file compare is the same as if you just ran it from the DC. The way some people manage versioning is to calculate and store the CRC of the seed copy and then check the CRC on just the local copy. "
Haha, I love it. How can you easily compare the CRC of both files with tools included in a standard build of windows?
I like the Makexe idea, the executable could trim uneeded code from the kix32 exeutable and turn out to be smaller than the original kix32.exe !
| ciper |
| (Fresh Scripter) |
| 2004-11-03 04:00 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
The slow links I mention arent slow in terms of speed its latency, point to point dedicated connections and VPN over the internet both get slow. For example a short run like boulder colorado to Toronto Ontario with a T3 is 95ms with the best provider. The smaller offices using 384k dsl with VPN are 160ms to 200ms usually
| ciper |
| (Fresh Scripter) |
| 2004-11-03 04:05 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Could I read the date of the two kix32.exe files and compare them? Then if I ever want a new version copied to the machine I just set the date into the future.
|
NTDOC
|
| (KiX Master) |
| 2004-11-03 04:10 AM |
|
|
Re: Kix32.exe is too large, I use an old version...
|
Well, just to maybe shed a ray of light on the subject as I see it.
On the UPX website forum for "Our Happy Customers" I see 59 posts.
According to Microsoft claims, they tested over 2 Million applications for compatiblilty with Windows XP before RTM.
When writing an application using Microsoft Assembler and Visual C v6.0 one has to make many choices for compiling for the best size. This process often includes hundreds of various resources that Microsoft has worked on compatibiltiy testing already to a degree further then any other vendor in this area.
I don't think anyone is disagreeing that it is not possible, but come on, one has to be realistic as well. This is not the only compressor out there and were not talking a 5MB+ DLL like many applications have.
The author writes KiXtart on his own time and has to debug on his own time to a degree he feels comfortable with making a beta version available. By now throwing in the mix a compression routine that has issues as well. (I see 132 posts for "Troubles with decompression of packed exes")
Your scripts can also be setup so that the user doesn't even see or know it's running, so what are we really talking about here? An IDEOLOGY which may or may not be accepted by everyone.
You can easily compress your version though as you already know and run along happy. I can't speak for Ruud, but if I were in his shoes I don't think I'd care to spend the extra time and effort involved to achieve such a small gain at the expense of potential unknown bugs or other issues.
As for the newer features in the lastest KiXtart, there are hundreds of minor fixes, updates, new features and yes, as Shawn has said, a LOT of current size is due to still maintaining Windows 9x support.
If you know of a smaller/better/as-complete scripting language please let us know.
Have you checked the size of Perl/Python/VBscript ? They are MUCH larger then KiXtart and require external libraries to support anything close to what KiXtart supports in a single EXE.
| Les |
| (KiX Master) |
| 2004-11-03 04:14 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
Haha, I love it. How can you easily compare the CRC of both files with tools included in a standard build of windows?
Hmmm... KiX is not included standard with WIndows but you use it. Neither is UPX.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 04:24 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
Really wierd ... I download upx and successfully compressed verion 4.22 of kix32.exe. strange thing is I get some kind of weird PF error (?) when compressing 4.50 alpha kix32.exe ... dont know whats up with that. using the same commandline switch etc !?
| Howard Bullock |
| (KiX Supporter) |
| 2004-11-03 04:29 AM |
|
|
Re: Kix32.exe is too large, I use an old version.
|
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.
| ciper |
| (Fresh Scripter) |
| 2004-11-03 09:18 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Thats true, I try to keep the number of support files to a minimum, so far the script uses/copies
cusrmgr.exe 78k (great for adding domain admins back into the local admin group using the users security)
pskill.exe 92k (able to stop processes that even taskmanager cant)
ntconfig.pol 256k (for control over xp sp2 firewall policy)
poledit and associated files 212k (only way to locally change firewall policy when controlled by policy)
urtlogon.exe 60k (changes users to vlan based on business unit)
3 reg files 7k (various settings to the desktop)
2 kix script 6k (service pack 2 deployment to users of certain business units, symantec antivirus install and mcafee uninstall)
5 batch files 11k (too much to explain)
and a batch file compiled/encrypted to exe to hide contents 58k (sets local admin password, checks for antivirus install etc..)
and some other random files like office template/font defaults
Overall about 800k
You didnt answer the question though! Ill try to look too and post what I find.
Quote:Quote:
Haha, I love it. How can you easily compare the CRC of both files with tools included in a standard build of windows?
Hmmm... KiX is not included standard with WIndows but you use it. Neither is UPX.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 09:22 PM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
ciper,
Have any feeling why upx would be able to compress v4.22 of kix32.exe, but using the exact same commandline, be unable to compress v4.50 of kix32.exe ? Have you seen behavior like this before ?
-Shawn
| ciper |
| (Fresh Scripter) |
| 2004-11-03 09:24 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Ill try crc32.exe, it will help with some other file version checking I have to take care of!
Im not doing much in the kix script becuase I have 12 batch files taking 23k in the netlogon share doing the majority of work, plus executables to make up for the missing parts in batch commands. Each of those is serving a different function too, all users in the domain point to the same main script.
I want to migrate the function over to kix but it takes alot of time and testing that I havnt found yet.
I wonder, is there some way to easily translate a batch file into a kix script automatically?
Quote:
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.
| ciper |
| (Fresh Scripter) |
| 2004-11-03 09:25 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Ill download a copy of 4.5, as the latest version I have currently 4.22 . Does it matter what compression level you use?
Quote:
ciper,
Have any feeling why upx would be able to compress v4.22 of kix32.exe, but using the exact same commandline, be unable to compress v4.50 of kix32.exe ? Have you seen behavior like this before ?
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 09:29 PM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
Didn't really muck with the parms too much, will try it later tonight ... The 4.50 alpha version of Kix32 is not publicly available yet.
| ciper |
| (Fresh Scripter) |
| 2004-11-03 09:38 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
No wonder I was having a hard time to find it
Have you started a thread in the UPX forums that I can join?
I was reading the "our happy customers" forum and found that IM client Jabber uses UPX.
Do KIX developers read these forums, or is there a better way to contact them? I think it would be great if KIX had UPX compression from the source. Im able to test most things on my own but it would be reassuring if the entire community was there testing it with me along with the author.
If you doubt the credability, you may want to visit the first authors web site
http://www.oberhumer.com/
Quote:
We are involved in a number of projects - doubtlessly the most exciting being the NASA MER project, where we have designed and implemented the lossless on-board data compression module for the NASA Mars Exploration Rovers, better known under the names Spirit and Opportunity.
| ciper |
| (Fresh Scripter) |
| 2004-11-03 09:49 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Does a thread exist to explain the extra code needed to support Win9X systems? I dont understand enough about the way kix works to know why.
The idea of a lite/stripped version wasnt acceptable then how about a NT/2K/XP only command line version?
If this existed, Id run different applications if the machine is XP rather than 2000 and skip if its 9X based. Something like
If "%OS%" == "Windows_NT" Goto 2000XP
GOTO NOTXP2K
:2000XP
echo is this windows XP? >> "%temp%\loginsteps.txt"
ver > "%temp%\ver.txt"
find /I "XP" "%temp%\ver.txt" > nul
if %errorlevel% == 2 GOTO OSCHECKBROKE
if %errorlevel% == 1 GOTO OSCHECKNOTXP
if %errorlevel% == 0 GOTO OSCHECKXP
GOTO END
I already have in the script to skip past machines that are servers (based on the first two letters of the name)
echo Check If server >> "%temp%\loginsteps.txt"
if not exist c:\temp\$PosLen.bat copy /Y %logonserver%\netlogon\$PosLen.bat c:\temp
call "c:\temp\$poslen.bat" %computername% 0 2
IF %$substring% == US GOTO ISASERVER
Poslen is super cool, lets you extract letters from a string at the POSition and LENgth you specify, and it runs without needing any support from an external application. You guys might find a use for it.
@echo off
setlocal
set $substring=
if {%1} EQU {} goto end
if NOT "%3" GTR "0" goto end
set $string=####%1####
set $string=%$string:####"=%
set $string=%$string:"####=%
if "%$string%" EQU "" goto end
set $string=%$string:####=%
for /f "Tokens=*" %%i in ('@echo %%$string:~%2^,%3%%') do set $substring=%%i
:end
endlocal&set $substring=%$substring%
REM end $PosLen
http://www.jsiinc.com/SUBI/tip4100/rh4191.htm
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 11:29 PM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
I dont think so, but basically to support 9x, Kixtart needs some extra support DLL's, and it needs an RPC service running on the domain controllers ... So kix32.exe has the extra "layers" of code, to talk to the DLL's that talk RPC to the service. Thats my take on it anyways. All this RPC stuff makes up for the fact that lanman services on 9x is domain dumb. (Anybody?)
|
NTDOC
|
| (KiX Master) |
| 2004-11-03 11:41 PM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
I view this as sort of like a Linux/Windows/Mac Holy War so not really much to say.
I don't view this as a CRITICAL ISSUE that is impacting CIPER's job or anyone else here that is at least vocal about it.
If Ruud picks up on this and wants to go that route, fine, but otherwise I don't see that there is a problem with KiX
|
Shawn
|
| (KiX Supporter) |
| 2004-11-03 11:45 PM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
I think he picked-up on it, just taking a different approach ... instead of decreasing the size of kix32.exe, and making the exe "faster", he implemented "tokenizing" and has decreased the size of the scripts, and tokenized scripts run faster... idk
| ciper |
| (Fresh Scripter) |
| 2004-11-04 12:14 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
NTDOC: I think you have spent too much time arguing on forums. Im just asking for a more streamlined version of KIX, this is the suggestion forum afterall. Is it the "stranger" title next to my name that makes you so harsh?
A WIN32 only version of KIX command line and also a "general purpose" version (with 9x support) seems like the obvious step to one day not supporting the older operating system. Once an OS has reached end of life by microsoft most companies will have switched already or have a migration plan in mind.
As I remember, Windows 95 released Aug 1995, Windows 98 released Jun 1998. So 95 is over 9 years old and 98 is over 6 years old. Im not saying to get rid of support for the old OS completely, but give the users the option to drop the chunk of code they will never use.
Now you could argue that Windows ME was released in december 2000, but Windows 2000 was released BEFORE it. I know of exactly 0 people who run ME on a corporate or home machine other than driver compatibility testing.
Is this the CRC32.exe mentioned previously? http://www.kzin.com/cgi-bin/page.cgi?/utillc/crc32
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 12:23 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
The 9x specific code in kix32 may or may not be sizable, for all we know it's insignificant, but on a more constructive level, if you were to browse through the latest and greatest help (chm) file for Kixtart, and suggest a few functions and features that should be "chopped" from Kixtart (not to be included in a smaller version of Kixtart), what would be on your short-list ?
-Shawn
| Les |
| (KiX Master) |
| 2004-11-04 12:46 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
I will reiterate that KiX should not have any commands/functions removed. I do feel though that Ruud can provide a pared down runtime EXE as per my MakeEXE suggestion, by removing the tokenizer and by the use of compression which he already uses on the tokenized script.
If you want a pared down command/function set, stay with the old version you are using now.
|
NTDOC
|
| (KiX Master) |
| 2004-11-04 12:47 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
No it's not the title of STRANGER, but yes I would say that I am a little put off by what appears to be your first post on this board.
Quote:
Not sure I understand the continual increase in size of the KIX executable over time. Are the developers getting lazy on optimization?
As I view it, that is a personal attack on the author whom I hold in high regards. Thus I would initially maybe have wanted to attack you back, but I did not. I pointed out (imho) what I felt were the tasks/issues/drawback/time involvment with using a Compression Algorithm against KiXtart. Now you seem to have switched course a little and are asking for two versions of KiXtart, which I originally did not reply to you about.
Again, I'm not saying that Ruud can't do such, but rather I do know that his time is VERY limited as he is no longer allowed to work on KiXtart at work, so just like many of us I would assume he has to balance his personal life with his family and work as well as his hobby (KiXtart).
I'm sure though that he might be quite willing to drop support for Windows 9x and leave current users of KiXtart at version 4.22 (but agian that is my opinion and may not be shared by Ruud)
Not trying to "argue" with you, just that I don't see much merit myself in your FIRST posting about compression, but I do agree there is merit in the idea of dropping Windows 9x support (not so much for the decrease in file size, but perhaps in allowing better/faster things to be done for the NT/2000/XP/2003 class of systems), in fact it would probably be great to quit supporting NT 4 as well, but think there is still a LOT of those systems around the World, but again maybe leaving NT 4 at v4.22 of KiXtart might not be such a bad idea either. After all it is quite a great little scripting engine as it currently is at 4.22
I apologize if you felt that I was attacking you personally as that was not my intent, but rather was meaning to point out that I did not see proof of merit for what you were asking and don't recall other users sharing the same issue either. That is why I see/saw it as something almost like the OS Holy Wars. Sort of like: "Gee, have you tried this cool new little toy, it's that best thing since sliced bread., Come on guys, you've got to try it." You didn't present it as a legitimate issue as I recall since you then went on to say how much bandwidth you did have, so agian I find/found it difficult to believe there is a real issue here that needs to be solved.
I do agree on the dropping of Windows 9x support and even NT from a going forward point of view and maybe a new topic for such should be started, but I still find it difficult to find a real need for the author to go out of his way to try and decrease the file size by such a small amount.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 01:01 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
In terms of the Kixtart developer (Ruud), I hold him in extremely high regard, respect him greatly. He's "stuck-with-it" over the years, way beyond when most developers would have lost interest long ago, hes still pluggin away at it in his spare time (what little spare time an MS principle consultant gets these days) ...
But here's what I really want to say ... I trust Ruud's judgement explicitly ! I've seen some really whacky ideas for new features thrown his way, some even not-so-whacky ones, but he has this "knack" for filtering out the junk from the truely important stuff, he probably agonizes over what goes into Kixtart and what shouldn't, it aint an easy call but I think he's done a great job.
| ciper |
| (Fresh Scripter) |
| 2004-11-04 01:44 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Tokenizing is an automatic inline operation I guess, the document doesnt mention it very often. Is it possible to output the tokenzied version of the script and use this later?
I didnt realize that only one person is working on the coding of KIX, I would agree its alot to ask someone with already limited time so why do it? Allow others with the knowledge to contribute to the work.
The first thing that comes to mind is VNC. Third parties have written some of the coolest VNC packages, with everything from domain authentication to dual screen support!
Although I still use NT, I wouldnt be against dropping its support either. It has also reached end of life by Microsoft. Not as many people still use it as you might think, its too much of a risk. If vulnarability is discovered effected 2k/xp which also effects nt and a virus is written to take advantage of it those NT machines will be screwed since Microsoft will not supply a patch.
I may have information that would be useful to the developer in deciding to drop support for certain OS. Will I get in trouble for sharing? Without being too vague, one of the products my company makes is in most of the homes with a computer or game console. On the computer side the application supplied captures the OS each person has and reports back. Let me ask someone if its okay to give it out if I dont identify the source.
So I found out I have two sources, one for what the applications report and another based on the the os each person has when they download the driver
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 01:58 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
ja, tokenizing works like this:
C:\> kix32 /t myscript.kix
this produces a file called "myscript.kx" (note the new extention .KX) ... this file contains byte code, looks like this:
՝֕ ƲŤֳ˨ڵƩϻٷӼ˸ ҷ٭ 8Д_ˀ
́ݎՖ2¡ Ϋڵ۽Գƴաȧ ;h;
T2F1P"GV?\.A2];OD-C'H?LS&T&C-Yjkm_b~ct({vvVw`A$W<H'WWqhM
your standard unreadable blob, then you can run this tokenized file back through kix32 like this:
C:\> kix32 myscript.kx
Depending on the script, and what its doing, you can get anywhere from 0 to 50% "compression" in size ... plus its already mostly "pre-parsed", so it should be faster ...
-Shawn
| ciper |
| (Fresh Scripter) |
| 2004-11-04 02:05 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Wow! Why is it not mentioned in the word document on the web site?
Is it possible to detokenize a file too?
Oh and I have a third source now. Some research firm called NPD? Supposedly its where everyone goes when they dont have data of their own. http://www.npd.com/ Someone is going to give me access to that data, then I dont have to share possibly confidetntial stuff
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 02:13 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
Can't detokenize the scripts - we dont want to be able to de-tokenize the scripts, Ruud will not be publishing information on how to reverse engineer the byte code (afaik).
Mostly because this tokenization process provides a bit of "code mangling" and security, so that some folk may take comfort in knowing that user's wont be able to read whats in the login script.
Even maybe to the point of allowing one to embed passwords in the login script - but please, lets not "go there" (the password thing), we would be opening up a whole new can of worms (trust me, we dont want to go there) ;o)
| Les |
| (KiX Master) |
| 2004-11-04 02:14 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
Wow! Why is it not mentioned in the word document on the web site?
It is not mentioned in the Word doc because it is still a private beta release but it is discussed in the beta forum. The concept of detokenization too is/was hotly debated.
| Les |
| (KiX Master) |
| 2004-11-04 02:19 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:tsk tsk
embed passwords
Shawn... bad boy... bad BAD BOY!
You just had to mention it didn't you! {sigh} Now I have to go into one of my rants again.
What Ruud does is not irreversable encryption but simply obfuscation. To quote him again:
Quote:
In general, you should never, ever, put truly sensitive information in any shape or form within the users security context. Whether or not passwords in scripts are truly sensitive depends on your specific situation.
| Howard Bullock |
| (KiX Supporter) |
| 2004-11-04 02:24 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
CRC32.exe is something I had compiled internally. You can find it at http://home.comcast.net/~habullock/kix_solutions.htm
| ciper |
| (Fresh Scripter) |
| 2004-11-04 02:26 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Dangit Shawn, you got me all excited. I though /t was part of the current release
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 02:36 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
sorry about that ... and I'm sorry that I mentioned the "password in login script" thing too, the lynch mob is already assembling.
| ciper |
| (Fresh Scripter) |
| 2004-11-04 03:18 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
If I can summarize:
Reverse tokenizing will not be supported because tokenizing is a method of security that we shouldnt be using in the first place?
I see an easy fix that makes both side happy. A flag used when tokenizing. Omit the flag and the script can be extracted, add the flag and the application wont let you.
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 03:35 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
No not really - like Les said, tokenizing is not a method of security, its a way to make scripts smaller and faster, thats it. Tokenizing only mangles scripts (by default), and the developer has already admitted that one day, someone may reverse-engineer the byte code (despite having no reference material), and that tokenizing shouldn't be thought of as "secure" (cause it aint really).
Havind said that, tokenization does make the script awefully hard to read, for the casual "hacker/snooper" anyways ... depending on the situation, this may be a good thing ... I would be pretty comfortable with it.
| ciper |
| (Fresh Scripter) |
| 2004-11-04 03:44 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
CRC32.exe is something I had compiled internally. You can find it at http://home.comcast.net/~habullock/kix_solutions.htm
Awesome, thanks. Do you have to specify the file size or can you skip this step just for the crc value.
Also the link your provide for usage example is no longer valid, I guess this site switched message board format a while back?
| Les |
| (KiX Master) |
| 2004-11-04 03:46 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
I disagree... well yes and no.
Tokenizing is obfuscation... plain and simple. It is a way to hide your source from casual reverse engineering. That said, those that want to obfuscate do not want reversibility.
| Les |
| (KiX Master) |
| 2004-11-04 03:48 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Here is a link to a discussion over at SL.
http://www.scriptlogic.com/forums/display_message.asp?mid=10260
|
Shawn
|
| (KiX Supporter) |
| 2004-11-04 03:51 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
One of our night-shift Moderators ;0) ... Richard H. from the U.K., wrote a neat utility called kixcrypt (look it up), it takes a script and encrypts it (using a proprietary algorithm that Richard keeps under his hat), and bundles it up into a single EXE thats awefully hard to decrypt, probably a better way to go then tokenizing. There are lots of members that use kixcrypt and love it.
-Shawn
| Les |
| (KiX Master) |
| 2004-11-04 03:56 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Ja, but he seconded my suggestion for MakeEXE.
|
Richard H.
|
| (KiX Supporter) |
| 2004-11-04 03:10 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Shawn says...
Quote:
Richard/Cappy ... you guys got any comments to add on this thread, whats your views on "the size of kix32.exe" ?
Not really. It's pretty much all been said and I think this thread has probably run it's course.
As I've been asked, I'll pick up a couple of points made earlier and add my own commentary.
KiXtart has grown quite a bit, but that is due to new facilities, not the support of old ones. This is self evident in the fact that the bulk of the current code has come with recent releases. Removing support for older systems will return a very small reduction at the cost of compatibility. Don't forget that the Win9x specific code is stored in an external DLL, and this is required only for specific functionality. The rest of the code is KiXtart specific and API handlers which will be the same regardless of OS support.
Removing "old" operating system support will save you a few external function calls and a couple of string constants (such as @PRODUCTSUITE returns). Let's be generous and say it saves 2048 bytes. It's probably not enough to drop the compiled code below the boundary required to reduce the file size.
You could reduce the size of kix32.exe by (say) having a version without COM automation support, but you could do this just as well by using an older version.
As a quick sanity check, here is a question for you:
Q. What is the most prevalent and probably lamest script interpreter available for the Windows environment? One with very limited features and klunky built-in commands and functions?
A: The batch interpreter, CMD.EXE
Now, how big is yours?
| ciper |
| (Fresh Scripter) |
| 2004-11-04 10:43 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
No comments on using inline compression on the kix executable? I spent alot of effort comparing the different applications available for this and I would hope the contributors to this thread research UPX.
Make sure to view the corporate site for the developers of UPX, in order to establish credability. If you use Jabber or TurboIRC these have UPX from the source.
It may not be the best way to prove, but why do so many virus use UPX compression?
Richard H: "A: The batch interpreter, CMD.EXE"
cmd.exe on my system is 382k, which is bigger than the latest version of kix. However cmd.exe is included on every windows version used so no need to copy or run cmd from a remote location. CMD has an interactive shell too.
Hey, that could be interesting. A modification to the debug portion of the kix executable where instead of walking though a script you can type the commands on the fly
| ciper |
| (Fresh Scripter) |
| 2004-11-04 11:25 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Okay, I have some data. This is a sample from just under 200k machines, that reported back in a 2.5 month period ending in september. The software installed with one of the devices reports back data including OS. I removed the specific amounts/percents from each and combined them at the bottom. Realize this data is biased towards people who use some type of internet connection.
7 OS versions are detected:
4.10.1998 Win 98 Gold
4.10.2222 Win 98 Second Edition
4.90.3000 Windows Me
5.0.2195 Windows 2000
5.1.2600 XP Pro
5.1.2600+(Home)+ XP Home
5.2.3790 2003 Server
% 9x Platform 17.47%
% NT platform 82.53%
I have to say more 9x based than I expected.
| Bryce |
| (KiX Supporter) |
| 2004-11-05 04:59 PM |
|
|
Re: Kix32.exe is too large, I use an old version.
|
Quote:
Hey, that could be interesting. A modification to the debug portion of the kix executable where instead of walking though a script you can type the commands on the fly
or run this script......
Code:
while not @error
? "KixCL:>"gets $_c
$ = execute($_c)
loop
Bryce
| Sealeopard |
| (KiX Master) |
| 2004-11-06 12:40 AM |
|
|
Re: Kix32.exe is too large, I use an old version.
|
Windows ME on a corporate network?
Shudder.I really have to wonder why you're so obsessed with squeezing every single bit out of KiXtart and the associated scipts? Have you checked how much other network traffic you're generating by e.g. regularly updating Winodws-based computers?
Also, an intelligent network design will enable you to host e.g. login scripts on computers in the local network. Additionally, by paring down the login scripts to the essentials that are to be performed during a login process you'd most likely get better savings. Anything not directly related to login processes should be moved into centralized admin scriptsa that make configuration changes remotely.
| Ruud van Velsen |
| (Hey THIS is FUN) |
| 2004-11-08 03:37 PM |
|
Re: Kix32.exe is too large, I use an old version.
|
Hi everyone,
first of all, I have to say that the length and depth of your discussions never stop to amaze me! It's this kind of input that keeps KiXtart alive and helps me shape its future
On the size of the KiXtart exe: yes, it's grown over the years and yes, I have looked at ways of shrinking it. However, the reality is that it really is quite small as-is. Apart from throwing out really big things, like 9x support or indeed COM automation, there is not a lot that can be done to decrease the size of the EXE. In fact, it will grow if I ever get around to adding a proper icon to it, for example
.On creating a 'trimmed down' version: I've considered creating a 9x specific version several times over the years. Up until now, I've decided against this approach, as it would introduce deployment challenges for environments with 9x/NT/XP clients.
Thanks for your support and keep posting!
| ciper |
| (Fresh Scripter) |
| 2004-11-10 03:36 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
sealeopard: You misunderstood the source of those numbers. That is a representation of the average HOME user!
If I was to post the corporate world numbers the amount of 9x machines would be FAR less. Im still trying to get a copy of the NPD data which should show this.
| ciper |
| (Fresh Scripter) |
| 2004-11-10 03:44 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
This board supports polls right?
Why not have a simple aproach to this. Have a respected board member post a poll with the rule that you cannot reply, only vote.
The choice would be
1. I use KIXtart on a windows 95 98 or ME machine
2. I use KIXtart on NT 2000 XP 2003 machines
Leave the poll open indefinitly. The contributors to this board are the people who use KIX, that would be the most accurate representation of what the KIX community needs.
| ciper |
| (Fresh Scripter) |
| 2004-11-10 03:51 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Ruud van Velsen: I have a question. You made 9X support into seperate dll files. Was this so that I can choose not to copy these extra files in order to reduce the size of the KIX application?
Well why not follow the same idea for the com portion? Then if you need this functionality you copy the com.dll file along with the Kix32.exe. Otherwise you skip the com.dll and have a small version of KIX32.
|
Lonkero
|
| (KiX Master Guru) |
| 2004-11-10 10:06 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
nice idea.
in general.
but we are not living on win9x!
at least I want to keep it simple, tight and mean.
with extra dll's floating around and stuff like that, no go.
and remembering the hastle from new kixers about how they install and use kix, current dll's in the zip should not be in same folder as the executable.
| Ruud van Velsen |
| (Hey THIS is FUN) |
| 2004-11-10 10:43 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
The 9x support code uses so-called 'thunking' to get from 32-bit to the old 16-bit NETAPI.DLL. This technique is only supported on 9x itself. If it were built into the main executable, the executable would fail to run on anything but 9x. This is why the 9x support code is in separate DLL's.
Atually, if it had been possible, I would have built everything into a single EXE, just to keep the distribution and installation hassle to a minimum.
On COM interop: it's an interesting thought, but unfortunately we are not talking about a few calls tacked onto the engine. In reality, COM automation is tightly woven into the engine itself. If at all possible, moving COM interop to a separate DLL would be a massive amount of work.
Still, thanks for the input, keep it coming.
Ruud
| Sealeopard |
| (KiX Master) |
| 2004-11-11 01:01 AM |
|
|
|
Re: Kix32.exe is too large, I use an old version.
|
I'd rather see new functionality integrated, e.g. ByVar/ByRef support, or full COM-support, rather than getting a couple of bytes shaved off the executable. Once one figures in the size of the scripts to be run and the execution times, the size of the executable itself becomes meaningless.
| Jack Lothian |
| (MM club member) |
| 2004-11-18 02:56 AM |
Re: Kix32.exe is too large, I use an old version.
|
Amazing thread. I haven't seen you bunch so animated in years (years?). Even Bryce got involved. The thread started off kind of snarky but half way through it got interesting. Reminds me of the old days.
| Kdyer |
| (KiX Supporter) |
| 2004-11-24 09:14 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
Size of W/KIX32.EXE? What? Are we still running QEMM/Deskview to run a BBS from a home system? With today's computers and underlying structure, is there a big deal of a couple hundred K vs eighty K?
Kent
|
Lonkero
|
| (KiX Master Guru) |
| 2004-11-24 09:20 AM |
|
Re: Kix32.exe is too large, I use an old version.
|
no big deal, but wouldn't it be weird if we couldn't find anything wrong in kix?
not wrong, but something that makes it imperfect anyways...