Need a fast "comspec" shell for Windows
Terry Newton
This is probably a "tough" one but giving it a
shot in case anyone here has been down this road...
I need a FAST Win32 console command interpreter
I can set comspec to for the purpose of quickly
running a binary and redirecting the output to
a file, classic %comspec% /c program args > file
stuff. This is for programs that evolve warriors for
the game of corewar by shelling pmars or another
corewar interpreter millions of times while making
adjustments to the code. Under Linux I can get
well over a hundred shells per second but under
Windows XP I'm lucky to get 20 shells per second.
Cmd.exe seems to be too bloated, replacement
shells look even worse since they're all about
interactive glitzy GUI's and many don't support
running programs via comspec /c. I can set
comspec to the dos command.com and improve
speed by about 50%, better but has side effects
from switching between dos and win modes.
So... looking for something really simple that's similar
to command.com but compiled as a 32-bit console
program. All it has to to is run a binary and capture
its output via redirection, built-in command syntax
doesn't matter so long as it parses /c and redirects.
I know it's a strange request... but any ideas?
Terry
Ted Davis
> Hello all (especially old-timers:-),
>
> This is probably a "tough" one but giving it a shot in case anyone here
> has been down this road...
<snip>
>
> So... looking for something really simple that's similar to command.com
> but compiled as a 32-bit console program. All it has to to is run a binary
> and capture its output via redirection, built-in command syntax doesn't
> matter so long as it parses /c and redirects. I know it's a strange
> request... but any ideas?
Try putting CMD.EXE in a ramdrive, or for that matter, bash (if Cygwin is
installed) and pointing COMSPEC to the ramdrive version.
--
T.E.D. (tda...@mst.edu)
Terry Newton
> On Sat, 31 Oct 2009 14:59:11 -0700, Terry Newton wrote:
> > So... looking for something really simple that's similar to command.com
> > but compiled as a 32-bit console program. All it has to to is run a binary
> Try putting CMD.EXE in a ramdrive, or for that matter, bash (if Cygwin is
> installed) and pointing COMSPEC to the ramdrive version.
I used a short BASIC test that shells pmars 1000 times with
a short warrior. Ubuntu (Linux) it runs in 7 seconds compiled
or not. Under Win XP with the default cmd it runs in 47 seconds.
Whether compiled with FreeBasic or interpreted by Blassic.
Dos QBasic (using command.com) runs it in 23 seconds.
Windows with comspec set to command.com = 30 seconds.
Windows with comspec set to freecom.com = 32 seconds.
Copying cmd.exe and command.com to a ramdisk makes
little difference, cmd.exe time remained 47 seconds,
command.com time was slightly better at 29 seconds.
I tried sh.exe and bash.exe (add -e after filename) from
both cygwin and msys - 49 seconds and 48 seconds.
powershell.exe also takes 47 seconds.
I'm seeing a pattern here, my guess is all the Win32 shells
are loading the same or very similar DLL's with every shell.
The dos times would probably be much better if not for all
the mode switches between dos and Windows.
This isn't for anything important (the command.com
solution will do for now, myself I just run the Linux versions
and gain an advantage in the game) but it's a programmer's
challenge. Probably solveable with a bit of C that looks for
redirection, if none then just execute otherwise do an
open-pipe type exec to capture stdout and write to the
redirected file. Just thought I'd inquire in case anyone
knows of an easier way to do this. It's all fun.
(but like a lot of fun stuff can be useful down the road)
Terry
Ted Davis
> myself I just run the Linux versions and gain an advantage in the
> game) but it's a programmer's challenge.
I think you learned somethng about Windows vs. Linux. I use both, and
write scripts in gawk that run the same under both ... or should. One
script that shells other scripts fails miserably under XP for subprograms
with different length filenames - different lengths fail on differnt
machines, but the behavior is consistant over time for the same machine
(though not all files with the same length name, or the same file fail
every time). Needless to say, I run it for real under Linux and access the
results through Apache on the Linux system.
--
T.E.D. (tda...@mst.edu)
Terry Newton
> On Sat, 31 Oct 2009 22:45:43 -0700, Terry Newton wrote:
> > myself I just run the Linux versions and gain an advantage in the
> > game) but it's a programmer's challenge.
>
> I think you learned somethng about Windows vs. Linux.
Not sure I like what I learned... but I think I found a
workaround. FreeBasic has exec (file,args) and if a
program is already running in a console, stdout goes
to the existing console. FB also has a link to the
"freopen" C function which can redirect stdout to a file.
Getting stdout going back to the screen again without
disrupting it is tricky but doable. Preliminary tests
are encouraging, it's as fast as command.com
under VirtualBox (normally dog-slow) so it should
be quite fast under real Windows. Maybe.
So... all the pieces are there, just need to write a
"fastcom.exe" app that comspec can be pointed to.
Basically write my own (very stripped down) command
interpreter. Needs to add .com .exe, search the path,
process redirection etc like normally expected and for
compatibility if passed something it doesn't know then
hand it off to the real cmd.exe. Sounds like a plan.
I don't like programming for Windows (at least not
low-level stuff like this - I'm ok with it when I can
just recompile my source and it works), but so long
as most of my readers use Windows, there will
be a desire to make my little toys work well there
even if it's not my preferred hacking platform.
Terry
Klaus Meinhard
> So... all the pieces are there, just need to write a
> "fastcom.exe" app that comspec can be pointed to.
> Basically write my own (very stripped down) command
> interpreter. Needs to add .com .exe, search the path,
> process redirection etc like normally expected and for
> compatibility if passed something it doesn't know then
> hand it off to the real cmd.exe. Sounds like a plan.
If you're looking for a command line shell take a look at
www..jpsoft.com 's TCC/LE. Its the (free) NT type os successor to 4DOS
andhould fit your needs.
--
Best Regards,
* Klaus Meinhard *
<www.4dos.info>
Terry Newton
> Hallo Terry,
Hello Klaus
> > So... all the pieces are there, just need to write a
> > "fastcom.exe" app that comspec can be pointed to.
...
> If you're looking for a command line shell take a look at
> TCC/LE. Its the (free) NT type os successor to 4DOS
I saw TCC/LE but I didn't realize it was related
to 4DOS, will check it out. I've already coded
a compact solution called "binrun" and incorporated
it into the app that needs it, also available
separately. If needed enter MEVO evolver into
a search engine, there's a link to binrun in the
comments section of the MEVO page.
Took a bit over 3K of FreeBasic code.
Terry
charles
wrote:
That would have been my guess too. However, on an XP system I ran a
timed 500 rounds for loop, shelling out of a parent cmd.exe process of
course, invoking the shells with a minimal .bat with the following
results:
C:\windows\system32\cmd.exe /c"C:\bat\donothing.bat" 14 seconds
C:\tccle\tcc.exe /i /c"C:\bat\donothing.btm" 25 seconds
I was surprised based on what I've heard about TCCLE's speed. I assume
that invoking the command in a parent cmd.exe for loop has something to
do with it but having to learn TCCLE's own for loop syntax is another
issue.
Klaus Meinhard
> That would have been my guess too. However, on an XP system I ran a
> timed 500 rounds for loop, shelling out of a parent cmd.exe process of
> course, invoking the shells with a minimal .bat with the following
> results:
>
> C:\windows\system32\cmd.exe /c"C:\bat\donothing.bat" 14 seconds
> C:\tccle\tcc.exe /i /c"C:\bat\donothing.btm" 25 seconds
>
> I was surprised based on what I've heard about TCCLE's speed. I assume
> that invoking the command in a parent cmd.exe for loop has something
> to do with it but having to learn TCCLE's own for loop syntax is
> another issue.
Its seems to me you timed primarily the loading time from your hard
disk, which may be slightly longer for the larger TCC.EXE. Try to time
some something that uses only memory, and try to compare cmd's insane
FOR with TCC's much more readable and flexible DO ... ENDO loop.
Richard.Williams.20
You should use biterscripting instead. It is much faster than cmd and
comes very close to unix/linux style shell command interpreter. You
can find several sample scripts posted over the web and at
http://www.biterscripting.com .