Announcement

**David Roberts** · 4 Apr 2003, 06:13 PM

The point of the batch file was to get errorlevels from scanreg
so I implemented, via a pbu, Exec by Keith Foster from Lance Edmonds' post
March 5 2001 "return values from shelled programs"

The exe increased from 63559 to 63780 which is neither here nor
there but it still took 9.4 seconds.

I would have thought Exec would leave the batch file method standing
since the latter writes the bat, shells out creating a txt with the
errorlevel, txt is read and then both the bat and txt are killed.
A sledgehammer to crack a nut but no worries about SETMEM!

Not killing the bat and running from the desktop comes back in about
1 second in line with the 1st app where the orig code was pasted from.

Something is wrong here - Exec should have stormed home.

------------------
David Roberts

**David Roberts** · 4 Apr 2003, 07:44 PM

I've run scanreg in DOS and it took 3 seconds to scan the reg.
A Exec version took 10.4 seconds to do the same and bring back
an error level.
I hadn't realised how slow PowerBasic is!
I'm now wondering how on earth the 1st app is managing to come
back as fast as the batch file!

------------------
David Roberts

**Lance Edmonds** · 5 Apr 2003, 08:18 AM

The bottle neck is not very likely to be PowerBASIC as you suggest, but as you have not provided the actual code for anyone else to try, and we don't know if you are testing both apps from the same command-line or if you are using different DOS windows, or whether you have other apps running that are stealing CPU time in big quantites, or...something else again.

At this point, the best we can do is guess what is going on. First, how many PC's have you made the comparison on?

Also, the Windows multi-tasking settings could easly explain the problem. Specifically, the "idle sensitivity" setting could be much lower on the "faster" app. Do you know how to adjust the Properties of a DOS window.

Next, how does the execution speed compare when you run it in plain MSDOS mode (ie, boot to the command-line, not to Windows)?

The first step to investigating the problem would be to write a very simply app that simply runs the .BAT file, and reports the time taken to perform the task. This will hopefully eliminate the other code in your app as a possible cause of the problem.

For example, you might write something simple, like this:

Code:

$COMPILE EXE
$ERROR ALL OFF
t! = TIMER
SHELL "x.bat"
PRINT TIMER - t!

To test this code, you'll need to execute the EXE from a DOS command-line, and stick to using the same DOS command interpreter and DOS window to run all the tests to eliminate shortcut/PIF file configuration as a cause of the problem.

If this code runs fast, then chances are the problem is something else in your real program, or it could be that your test .BAT file is having a much greater impact on system speed than you might have imagined.

OTOH, if the speed is low, then you might check that the command-interpreter is working ok, and that there is plenty of free space on the drive, and the root folder is not full.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**David Roberts** · 5 Apr 2003, 09:02 AM

Hello Lance

I have a scientific/statistics background so when comparing fighters I make sure they are in the same ring and at the same time.
Of course, there may be one or two variables that are different between the camps and they are being looked for.

Your code snippet is almost identical to the one I have been using.

In DOS, I'm getting 3 v 10 secs as opposed to 2 V 9 secs [roughly].

I'm in the process of stripping the code down to the bare minimum and I'll post the result of that.
Of course, if the loss of speed goes then I'll have stripped something off which is causing the problem.

I'll be back.

Cheers.

------------------
David Roberts

**David Roberts** · 5 Apr 2003, 11:33 AM

Yeah, the loss of speed went whilst I was stripping the code down.

The errorlevels are considered in a select construct. Case 0 is large(ish) & the most likely scenario so I put an END before it and ripped it out.

I got my <2 secs back. Put Case 0 into a Gosub and back to 9 seconds.

So, it's got nothing to do with the bat file.

I'll leave Case 0 alone and strip elsewhere. If I cannot get back to <2 secs I'll consider Case 0.

------------------
David Roberts

**David Roberts** · 5 Apr 2003, 12:59 PM

I've ripped other code out and got <2 seconds so it's not Case 0 - it's the exe size.

It's currently sitting at 63850 bytes.

I've never concerned myself with size. I have one app at 87223 and there have never been any problems with that.
So, I duplicated a few routines to make the 62K app larger but that didn't help.
I've thrown in a $segment here and there but no help.

I'll shuffle the code around and see what happens.

Seems odd. The program works - it's just that at it's current size shelling out takes 9 secs instead of 2.

------------------
David Roberts

**Lance Edmonds** · 6 Apr 2003, 06:47 AM

Over the years I've written hundreds of apps with PB/DOS that range from a few KB to 250-300Kb and I've never experienced a problem with a "slow" SHELL, so I'm still suspicious that something else in your app is having a big effect.

While your EXE size might be quiet small, the memory image size of the app and the amount of free memory are much more important aspects. Have you compared the results of FRE(-1) and FRE(0) between your two apps before the SHELL statement?

Also, to help eliminate low-memory problems, you might try referencing the FRE(0) function and issue a MEMPACK before the SHELL, just to maximize available memory. (completely compressing fragmented memory can be a bit more complex than this, but its worth at least an initial investigation in your apps).

As an aside, low conventional memory can be a major concern when SHELLing to external apps, so I routinely make use of UltraShell from www.informs.com - I highly recommend it to solve any free memory-related problems. US works buy swapping out almost the entire conventional memory area to EMS or to a temporary disk file, leaving around 5Kb in use. This ensures that the SHELLed app will be able to use almost the entire conventional memory area for it's operations.

Good luck!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**David Roberts** · 6 Apr 2003, 07:30 AM

Quite a few months ago I had a problem with a large registry and had a massive clean out of rarely used apps and I also examined the conventional memory status and found room for reduced usage.

I always use MEMPACK before shelling out.

This is what I have just before shelling out.
46K app fre(0) 32750 fre(-1) 516832
62K app fre(0) 32750 fre(-1) 501792

So, I am awash with conventional memory.
scanreg, the app I'm shelling, can use an enormous amount of memory in a DOS context I doubt I am pushing the limit with my current registry.

The odd thing is an app using Exec with only a handful of lines is also taking in excess of 9 secs to complete.
Using Exec on other progs which generate errorlevels is coming back to me in millisecs.

I'll try and get access to another PC.

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 12:45 PM

Just a quick word.

Exec threw a wobbly on an unrelated exercise. DOS needed more parameters. I tried another routine which which needed several but also was happy with none. In each case it Exec behaved as if given none.

So, I wrote another pbu using your 2nd suggestion from your post cited above.

For the record this is how it was entered in my machine.

$CPU 80386
$LIB ALL OFF
$ERROR ALL OFF
$OPTIMIZE SPEED
$COMPILE UNIT

FUNCTION EXEC( BYVAL program AS STRING, BYVAL par AS STRING ) PUBLIC AS INTEGER
DIM block AS STRING * 14
DIM parm AS STRING * 50
DIM zbuffer AS STRING, dummy AS LONG
zbuffer = program + CHR$( 0 )
LSET parm = CHR$( LEN( par )) + par + CHR$( 13 )
LSET block = CHR$( 0 ) + CHR$( 0 ) + MKI$( VARPTR( parm )) + MKI$( VARSEG( parm ))
dummy = SETMEM( -500000 )
REG 1, &H4B00
REG 9, VARSEG( block )
REG 4, STRPTR( zbuffer )
REG 8, STRSEG( zbuffer )
REG 2, VARPTR( block )
CALL INTERRUPT &H21
IF REG( 0 ) AND 1 THEN
exec = 255
SELECT CASE REG( 1 )
CASE 1, 2, 3, 5, 8, 10, 11
dummy = SETMEM( 500000 )
EXIT FUNCTION
END SELECT
END IF
REG 1, &H4D00
CALL INTERRUPT &H21
exec = REG( 1 )
dummy = SETMEM( 500000 )
END FUNCTION

and I tested it using the following:

$INCLUDE "PB35.INC"
DIM ErrorL AS INTEGER, t as single, mem as integer
t=timer
mem=fre(-1)\1024
ErrorL=Exec("c:\windows\command\scanreg.exe","/nop /win")
print timer-t;mem
if ErrorL=254 then print "Not enough memory"
if ErrorL=253 then print "File not found"

I kept reducing the conventional memory allocation via the Total entry on the Memory tab of the Properties sheet.

I got 'Not enough memory' with mem @ 241K and the app worked with mem @ 281K.
On Auto mem was @ 525K. With a 40K step we cannot get an exact figure but there seems to be at least 244K not used by scanreg.

The app above takes over 9 secs on my machine; about the same as the 62K app (which does a lot more besides)using the bat file method.

This questions the 46K app using the bat file method.

I renamed User.dat from the desktop, after taking a valium[!], and all three apps agreed that one of the reg files was missing so the 46K app is working proerly.

You may not recognise the scanreg switches - it would take too long, here anyway, to explain what I am up to.

Cheers.

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 12:50 PM

Oh, I changed PBEXEC to EXEC to save time changing the library builder and so on.

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 03:08 PM

What I hadn't tried was the new version of Exec in DOS.
Down to 3 secs so the first version of Exec is suspect somewhere.
The scanreg switch /win is dropped when in DOS.

It's getting a bit heavy for me to figure out why the new version of Exec doesn't like working within a Windows session.

All I need to do now is fathom out why that 46K bat method is so fast in Windows.

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 03:42 PM

I've got the 62K app coming back in 3.5 secs

by shell "start /w prog.bat" ----- (1)

If I use start /w scanreg... in the bat file I lose the gain.

Reverse the start /w and no effect.

So, Exec in DOS and bat file method in Windows with (1).

Strewth!

I get two instances of command.com in Windows but what the heck.

Doing the same with the 46K app comes back in 1 sec but occasionally will slow to 3 secs. It is consistent without implementing start /w.I suppose this is another example of DOS not being happy at sharing a bed with Windows.

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 08:53 PM

Oh dear. I have not been able to repeat the new Exec success in DOS.

Using the above pbu I ran this in DOS:
-----------------
$INCLUDE "PB35.INC"
DIM ErrorL AS INTEGER, t AS SINGLE, save1t AS SINGLE, save2t AS SINGLE

t=TIMER
ErrorL=Exec("c:\windows\command\scanreg.exe"," /nop")
save1t=TIMER-t

t=TIMER
shell "scanreg.exe /nop"
save2t=TIMER-t
print save1t;save2t
-----------------

and got 10.93 3.74 with pretty much the same running another 6 times.

With an Athlon 600Mhz I've got an Atari ST next door laughing at that 11 secs!

------------------
David Roberts

**David Roberts** · 6 Apr 2003, 09:24 PM

For the sake of completeness here's the sledgehammer code:

$INCLUDE "PB35.INC"

DIM ErrorL AS INTEGER, t AS SINGLE

OPEN "Scan.bat" FOR output AS #1
PRINT #1, "@echo off"
PRINT #1, "scanreg /nop"
PRINT #1, "for %%e in (0 2 249 250 251 252 253 254) do if errorlevel %%e set errorl=%%e"
PRINT #1, "> error.txt echo %errorl%"
CLOSE #1

IF NOT exist( "scan.bat" ) THEN
PRINT " Scan.bat not found. Program terminated"
END
ELSE
t = TIMER
SHELL "scan.bat"
PRINT TIMER - t
KILL "scan.bat"
END IF

IF NOT exist( "error.txt" ) THEN
PRINT " Error.txt not found. Program terminated"
END
ELSE
OPEN "error.txt" FOR INPUT AS #1
INPUT #1, ErrorL
CLOSE #1
KILL "error.txt"
END IF
PRINT ErrorL

This is the original stuff that worked for the 46K app but not the 62K app.

In DOS the above came back in 3.9 secs. The cost in getting the errorlevel is negligible and surprising given all the disk access.

I've noticed your having a go at members for not supplying code.
My last few posts will cost you a few coffees!

Cheers

------------------
David Roberts

**Lance Edmonds** · 7 Apr 2003, 07:06 AM

Hi David,

I'm a bit confused by your last sequence of posts - what are the two different versions of EXEC() that your refer?

However, rather than going around in circles, can you please ZIP and email the various forms of the code and I'll run them on my Win98 box and see if I can get similar results or spot anything problematic.

Thanks!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**David Roberts** · 7 Apr 2003, 07:29 AM

Hi Lance

Ref Topic: 'return values from shelled programs'
Exec V1: Your post March 05 ,2001 04:22AM
Exec V2: -do- 04:24AM

The 2nd version was actually called PBExec but, for convenience, I used the same name.

The 1st version didn't work for me. It seemed that the parameter string was being read as empty. Exec V2, PBExec, worked OK.

I'll knock out a ZIP file and email it as requested.

------------------
David Roberts

**Lance Edmonds** · 8 Apr 2003, 11:55 AM

Update: David advised that SCANREG requires very close to 600Kb of conventional memory or it slows down substantially. The differences discussed earlier in this topic are caused by the slightly differing amounts of free conventional memory available when the SHELL/EXEC starts SCANREG.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**David Roberts** · 9 Apr 2003, 06:14 PM

Just a final note.

That 600Kb includes the additional conventional memory used by Windows and the DOS app. Running scanreg from the DOS prompt would find a lot more memory.

Got a copy of UltraShell. The additional memory got by paging the app to XMS resulted in the app scanning at 1.2 seconds which is one heck off a lot better than 9!!!

------------------
David Roberts

Announcement

Shell "prog.bat"

Shell "prog.bat"

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment