#20152 - 2002-04-18 08:37 PM
BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
I've seen programs that convert batch files to .com or .exe files. Would it be wortwhile to create a script or program that converts .bat to .kix?
If I'd want to try a project that will do this, where should I start? Anyone interested?
Brian
|
|
Top
|
|
|
|
|
#20154 - 2002-04-18 10:34 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Hmm. Mark, you're probably right about it being pretty complex. However, it might be a good exercise that can lead to other things...
In response to your points:
1. Handling switches would be difficult, but possible.
2. Various versions don't particularly present a problem. If I'm converting 100% to kix, then the resulting code should work exactly the same on different version, whether or not I have the same cmd, command, etc., so it comes down to my processing engine.
3. Piping and redirection -- I think in processing a script, you have to make multiple passes. As each line was processed, the script would have to determine what inputs and what outputs were contained in each line, keep track of that information, then see what other lines use the information and what information is discarded. Finally, the external inputs would be differentiated from inputs that are received from other lines in the script. When this is completed, a script could be formulated that discarded all unnecessary pieces. Definitely, this could be a bit difficult and take some time to figure out, but I don't think it's impossible.
4. Batch tricks would be handled by line by line processing. Because .bat files are handled line by line, it still is not difficult to figure out what the actual inputs and outputs should be for a given line. After all is said and done, the processing engine could ask the user if certain outputs (loose ends, like files used for processing) were needed before doing the actual code.
5. Many functions of popular DOS extensions could be incorporated. This would be the most difficult part. In the end, the kix conversion may be simply a shell to use the external program.
....
Brian
|
|
Top
|
|
|
|
|
#20155 - 2002-04-19 01:54 AM
Re: BAT2KIX
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11631
Loc: CA
|
Except you would still need a BATCH to call your script for Win9x systems. ![[Eek!]](images/icons/shocked.gif)
|
|
Top
|
|
|
|
#20156 - 2002-04-19 02:09 AM
Re: BAT2KIX
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Things that come to mind with this..
- READPROFILESTRING/WRITEPROFILESTRING
- READLINE/WRITELINE
- REGISTRY Manipulation
I know there are others.. Some of this is covered with Resource Kit Utils, but then again you have to have access to them for your users.
Maybe instead of BAT2KIX, we should be thinking KIX2VBS? ![[Smile]](images/icons/smile.gif)
- Kent
|
|
Top
|
|
|
|
#20157 - 2002-04-19 02:53 AM
Re: BAT2KIX
|
MCA
KiX Supporter
Registered: 2000-04-28
Posts: 5152
Loc: Netherlands, EU
|
Dear,
Possible that it can be also VBS2KIX conversion.
Important for f.e. a BAT2KIX must be the necessary to do that. Simple to run a
working BATch file as KIX scripts is in our opinion not enough. Sometimes we must
migrate our programming code to another programming type, because the current
programming language on our mainframes becomes obsolete and we must convert it
to make it possible to maintain and to run our code. Normally such modification
will not be there dos & windows environments. Only Microsoft stops supporting
such software, but they can't prevent users to use them.
Also you must be-aware that such conversion creates a great amount of additional
code, which makes maintaining also hard. Such conversion tools are mostly usefull
to see what is happening with your code in a new environment.
At least most BATch files are small or very small which can easily convert by
KIX programmers.
greetings.
[ 20 April 2002, 22:17: Message edited by: MCA ]
|
|
Top
|
|
|
|
|
#20158 - 2002-04-19 04:35 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Thanks for your input, everyone.
I started working on it a little bit, and it appears that the hardest part would be supporting ALL the functions that can be handled in batch. There are a lot of functions that either have no direct support in KIX, or are stripped down with only the most COMMON features.
Theoretically (and maybe not too hard to code, either), you can read in each line and parse it, then figure out inputs, operations, outputs, and branch instructions then save this to a file. After all the lines have been processed, an algorithm can be written that matches all the inputs, outputs, and branches of each line in such a way to make tighter code.. BUT... how do you deal with functions that have no direct support in KIXtart?
Things like net user, or net time (to parse for the time on a remote server, not set it), or subst are not supported in KIXtart.
Converting the lines that can be converted directly may be useful, but each line that cannot be converted directly would have to be hand coded anyway, and may not be doable by kix internally.
I'm not totally ready to abandon the idea, but working on it and watching this bulletin board has given me another idea to work on that may be both easier to implement and more useful in the long run -- a script debugging engine.
(I'll start a new thread.. thanks again for the input.)
Brian
|
|
Top
|
|
|
|
|
#20160 - 2002-04-23 03:52 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
The biggest question I have is how the getobject and createobject functions behave differently in KIXtart vs. VBScript... I haven't really dug into VB Script that much, so I'm relatively green on the syntax. The object-oriented coding can get a little confusing to those of us who started in BASIC and moved to .bat and maybe Pascal... What would be the advantage of using Java over VB or vice versa?
KIXtart is so much easier to follow and understand, although the code doesn't seem nearly as compact or quite as powerful. Essentially, it appears to be somewhat of a bridge between batch and VBScript.
Brian
|
|
Top
|
|
|
|
|
#20161 - 2002-04-23 04:31 PM
Re: BAT2KIX
|
New Mexico Mark
Hey THIS is FUN
Registered: 2002-01-03
Posts: 223
Loc: Columbia, SC
|
Hi Brian:
I think as you really get started, you will see some of the limitations. The problem is that KiXtart is really complementary with batch programming, not a complete replacement (unless you're a glutton for punishment). There are things that KiXtart does easily (like I/O) that is much more difficult with the built-in command processor language, and things that CMD does much easier (like complex file manipulation) than KiXtart.
For instance, it would take many lines of KiXtart code to replicate the following commands I use somewhat frequently from CMD...
xcopy /c/h/e/f sourcepath destpath
or
dir /o:d /s /b dirpath
or
for %i in (dirpath\*.txt) find /i "mysearchstr" %i >> found.txt
For our logon script, I will go to much greater lengths to keep everything possible in the KiXtart script, since this helps prevent users from breaking out of the logon script. However, for other applications, I try to use each language to best advantage. Each has strengths and weaknesses. Considering that CMD/Command batch, KiXtart, and VBS are all freely provided, I try to use all of them where they fit best.
If you have read many of the threads on these boards, you will often see KiXtart 'gurus' recommend a command line solution to a complex question. This confuses folks sometimes... after all, can't I do EVERYTHING in KiXtart? The short answer is that it may be POSSIBLE to do anything you want in KiXtart, but it is not always DESIRABLE to try. (Though some of the folks here love finding ways to do the 'impossible' in KiXtart just to show it can be done.)
"To the person with a hammer, everything starts to look like a nail."
The biggest problem I see is that (IMO) KiXtart is significantly easier to work with than CMD batch. So if someone has created a lot of batch files they wanted to convert to KiXtart, it would probably be easier for them to learn KiXtart and convert / optimize the scripts manually.
Often I will choose an entirely different algorithm to accomplish a task in a different language. For instance, I use GOSUBs pretty heavily in KiXtart because it is pre-processed in memory, but I don't use the same type of structure nearly as much in batch files because a batch file is parsed line-by-line interactively, so looping and gosub-type structures are very inefficient. I would much rather try to use the FOR command for iterative commands than a GOTO / LOOP structure for the same reason. (BTW, if you REALLY want to get discouraged, try to replicate the full functionality of either the FOR or SET commands with all the weird little differences between versions of Windows and DOS.)
Anyway, just some thoughts... worth every penny no doubt. ![[Wink]](images/icons/wink.gif)
New Mexico Mark
|
|
Top
|
|
|
|
|
#20162 - 2002-04-23 04:50 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Mark,
Thanks for your enlightenment on the usage of various types of scripting languages. Although I agree with you in concept when referring to batch vs. KIX vs. VBScript, there are other factors to consider.
1. Management
2. Politics
3. Non-conformity of systems
4. WAN deployment
...
Although the first 2 are basically, the same, they have the power of two!.. 'Nuff said.
If I could do everything in KIX (via logon), I would at this point. There are many benefits to this:
1. Easier to use/understand than batch or VBScript
2. No need to deploy Kix32.exe to every workstation. It runs fine via netlogon.
3. Keeping things internal to the kixtart script minimizes troubleshooting headaches/platform differences.
4. Management has already approved the use of KIXtart for logon scripts (not so for VBScript.)
5. VBScript is updated by Microsoft and comes with SOME operating systems, but not all, which means that different OSes have different versions, and all need updating... especially whenever Microsoft decides to release a new security patch.
.....
After all that I said ^^^^^^ ... I would prefer to manage PCs without logon script. Whenever my organization has enough money to move everyone to Windows XP (by 2010, probably), then perhaps logon scripts will not be as necessary. Until that time, I try to make the script with the mostest -- using as little external code as possible. :-)
"To the IT person with the hammer, the monitor is the first thing to go, the brain the second"
Brian
|
|
Top
|
|
|
|
|
#20163 - 2002-04-24 02:22 AM
Re: BAT2KIX
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11631
Loc: CA
|
Brian
"After all that I said ^^^^^^ ... I would prefer to manage PCs without logon script"
Not sure what you mean by moving to XP. Automation is/probably always will be the best method of controlling PCs.
We have XP and Active Directory, and there is no MAGIC bullet to control the types of things in AD that can be done via Scripts, whether it be BATCH, KIX, VB, Java, Perl, etc...
There is power in automation via scripts that until someone can figure out how to "anticipate" what the Admin or User "might" want to do and offer it in a GUI, I don't think scripts will disappear.
As an Administrator your company is better off with you knowing more about scripts and different languages.
side note: By you saying that BATCH files are difficult, I take it (and maybe I'm wrong) that you are younger then 28 and have not "had" to use/control DOS in the past. I say that because most of the younger Admins we have say similar things.
Granted I don't use batch anywhere near as much as I used to, but it is still a VERY powerful tool.
|
|
Top
|
|
|
|
|
#20164 - 2002-04-24 04:02 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Actually, I do fairly well in batch. But, I am talking about it being difficult in comparison to kixtart. (I am actually 28...) Optimally, I would love to lock down all the client PCs and use the remote management tools that are being integrated in more recent releases of Windows. Presently we use Symantec Ghost software to clone PCs. This becomes a tedious process of configuring and validating software "images" for each type of PC. The organization I work with outsources helpdesk support (Unisys) and PC procurement services (also Unisys), so I do not have optimal control over the software that is being loaded on each PC.
This is an environment in which I am forced to do a lot of things with the logon script that I would rather not do. Unfortunately, upper level superiors balk at authorizing or purchasing tools that would make client PC administration easier, although they easily approve other types of big-brother monitoring software that (IMHO) clog up our bandwidth and cause compatability issues on the client systems. (sorry about the rant and rave... gotta get it out of my system once in awhile! lol)
Anyway, there are roughly 10 people that handle NT administration in my organization, so we do quite a bit here, however a lot of things fall to me because I am asked do in the logon script what we can't get approval to do in other (sometimes better) ways....
"Alas.. KIXtart is not only a great tool... It's a hobby. I am not a user, but an addict."
-- Brian
|
|
Top
|
|
|
|
|
#20165 - 2002-04-24 05:15 PM
Re: BAT2KIX
|
New Mexico Mark
Hey THIS is FUN
Registered: 2002-01-03
Posts: 223
Loc: Columbia, SC
|
Whenever anyone says batch scripting is hard, I agree with them. And I've been doing DOS since 3.1 (and CP/M and even older mainframe/mini operating systems before that), along with many other types and flavors of command-line / batch scripting. I'm one of those weirdos who actually wrote batch scripts that did things like calculation and complex string manipulation before MS added these capabilities.
While many command line interface things are much easier to do than most people think, there are many tips, tricks, and gotchas that command line weenies have picked up through the years and just take for granted. (You mean you didn't KNOW the easiest way to parse each line in a text file is with the FOR command? You didn't KNOW that you can use the SET command as a simple calculator for numeric strings?)
What makes batch scripting especially difficult is the downright weird things MS has seen fit to do with their syntax in order to maintain some semblance of backward compatibility. Just look at something as basic as environment variables. What does the following yield when run from a batch file?
@echo off
set ONE=abcd
set TWO=efgh
echo %ONE%TWO
echo %ONE%TWO%
echo %ONE%%TWO
echo %ONE%%TWO%
rem Demonstrate the difference in argument variable handling
echo %0%TWO
echo %0%TWO%
echo %0%%TWO
echo %0%%TWO%
rem Most non-DOS scripters might think this should work in both cases.
if %ONE% NEQ %TWO% echo They are different
set TWO=
if %ONE% NEQ %TWO% echo They are different
Oh, and don't forget that
set ONE=abcd
and set ONE = abcd
may be handled differently in different versions of DOS/CMD.
Now add the complexity and weirdness of the SET command to manipulate these variables and you can see how anyone can get confused.
Now for a bonus question -- what does this command do when executed from the root directory of an NTFS partition (NT/2K)? For all my ranting, it is a good demonstration of some of the power of the CMD interface. ![[Big Grin]](images/icons/grin.gif)
for /f "delims=*" %i in ('dir /b/ad/s') do cacls "%i" >> cacls.txt
Cheers,
New Mexico Mark
P.S. BrianTX... The previous command is a good example of just how complex it could be to try to do a decent BAT2KIX program. I seriously doubt this command could be reproduced with less than 50 KiXtart statements, even if we ignored the complexity of trying to parse it in the first place.
[ 24 April 2002, 17:33: Message edited by: New Mexico Mark ]
|
|
Top
|
|
|
|
|
#20166 - 2002-04-24 07:04 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
Thanks for your comments, Mark. I have already acknowledged the extreme difficulty of parsing and recoding batch. What I'm wondering is how the CMD.EXE is only 236KB and is able to parse so many variations of code. The trick would be to parse the code identically to CMD.EXE and find functions in KIX that mirrored the CMD functionality.... although I doubt I would have the patience to do such a thing. Obviously, the problem is that many CMD functions have no KIXtart equivalent. These particular lines could not be included, however a utility that parsed all lines EXCEPT these may still be useful in some situations.
NET USE --> USE
COPY --> COPY
Mkdir/MD --> MD
NET TIME --> SETTIME
%username% --> @USERID
REGEDIT /S *.REG -->WRITEVALUE, etc ** parsing a .reg file and creating the equivalent script would be easy.. might be a nice UDF..
ATTRIB --> SETFILEATTR
.....
These are just a few of the many conversions that could take place automatically. For the basic logon script that only maps drives and displays a message, this could be very useful, especially for people that are new to KIXtart.
On the other hand, perhaps it would be more worthwhile to simply create a reference chart of CMD functions/commands that map directly to KIXtart functions along with suggested syntax. This could be posted as a FAQ?
The command line you posted creates a file cacls.txt that lists the permissions of all the folders on the current drive.
Brian
|
|
Top
|
|
|
|
|
#20167 - 2002-04-25 05:50 PM
Re: BAT2KIX
|
New Mexico Mark
Hey THIS is FUN
Registered: 2002-01-03
Posts: 223
Loc: Columbia, SC
|
I'm not trying to give you a hard time, Brian. I appreciate people who present 'what if' ideas, and frankly I would love to find a way to do something to efficiently convert one language to another. But just like people language examples, at some point, it requires some 'understanding' of what the author intended:
English: The spirit is willing but the flesh is weak.
"Automatic" translation into Russian and back: The vodka is strong, but the beef is insipid.
CMD.EXE (and KIX32.EXE) can be so small for two reasons:
1. They are not trying to translate between two different sets of syntax rules.
2. All their parsing and syntax rules are 'compressed' into executable code.
I really like your idea for a DOS/KIX comparison FAQ. I have found comparisons between languages to be very helpful. I.e. The book, Unix for VMS Users. That would be an EXCELLENT way to go... especially if you covered some of the more subtle nuances of how a command is handled.
For instance, you could document the differences in how NET USE and USE handle combinations of adding, deleting, and "permanent" settings. It is those very differences that have contributed to the various "mapdrive" UDF's floating around out there.
Good call on that command line. I had a ball figuring out how to accomplish this recently for someone who had some permissions problems on just a few directories on a server, but he wanted to find *all* the directories with the same permissions. Of course, he had to do a little text processing on the output file, but he was eternally grateful for anything that kept him from having to manually look at over 7,500 directories.
NMM
|
|
Top
|
|
|
|
|
#20170 - 2002-04-25 07:57 PM
Re: BAT2KIX
|
BrianTX
Korg Regular
Registered: 2002-04-01
Posts: 895
|
So, are there any volunteers to work on this? I'm probably a bit better at problem-solving than documentation, but I can work on this to some degree in my spare time (which is starting to dwindle as there are numerous projects that will soon be encroaching on it). Hopefully, some of the "old-timers" on this bulletin board will chime in!?!
Brian
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 484 anonymous users online.
|
|
|
