#128899 - 2004-11-04 02:26 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
Dangit Shawn, you got me all excited. I though /t was part of the current release   
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128901 - 2004-11-04 03:18 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
 
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.
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128902 - 2004-11-04 03:35 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
Shawn 
 
 
Administrator
 
     
 
 
 
Registered:  1999-08-13
 
Posts: 8611
 | 
 
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.
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128903 - 2004-11-04 03:44 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
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?  
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128908 - 2004-11-04 03:10 PM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
Richard H. 
 
 
Administrator
 
     
 
 
Registered:  2000-01-24
 
Posts: 4946
 
Loc:  Leatherhead, Surrey, UK
 | 
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?  
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128909 - 2004-11-04 10:43 PM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
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  
  Edited by ciper (2004-11-04 10:58 PM)
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128910 - 2004-11-04 11:25 PM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
 
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. 
  
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128911 - 2004-11-05 04:59 PM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
Bryce 
 
 
KiX Supporter
 
     
 
 
 
Registered:  2000-02-29
 
Posts: 3167
 
Loc:  Houston TX
 | 
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  
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128913 - 2004-11-08 03:37 PM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
Ruud van Velsen 
 
 
Developer
 
     
 
 
Registered:  1999-05-06
 
Posts: 391
 
Loc:  Amsterdam, The Netherlands
 | 
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!  
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128914 - 2004-11-10 03:36 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
 
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. 
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128915 - 2004-11-10 03:44 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
 
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. 
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128916 - 2004-11-10 03:51 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
ciper 
 
 
Fresh Scripter
 
 
Registered:  2004-11-03
 
Posts: 36
 | 
 
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. 
   
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
#128918 - 2004-11-10 10:43 AM 
 
Re: Kix32.exe is too large,  I use an old version.
 | 
 
Ruud van Velsen 
 
 
Developer
 
     
 
 
Registered:  1999-05-06
 
Posts: 391
 
Loc:  Amsterdam, The Netherlands
 | 
 
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  
 
 
 |  
| 
Top
 | 
 | 
 
 
 | 
 
 
 | 
 
 
 
 
Moderator:  Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart  
 | 
 
0 registered
and 749 anonymous users online. 
 | 
 
 
 | 
 
 
 |