[comp.lang.pascal] Just for kicks -- Similar Exec-error

winfave@dutrun2.tudelft.nl (A. Verbraeck) (05/21/91)

In article <29446@hydra.gatech.EDU> bb16@prism.gatech.EDU (Scott Bostater) writes:
>In article <4cBo0AK00Vpg06BUV4@andrew.cmu.edu> mg2n+@andrew.cmu.edu (Martin G. Greenberg) writes:
>>Has anyone else seen/experienced this problem?
>> [...]
>
>I've written a similar routine for work myself.  Why are you using WRITELN?
>Are you sure you want the extra CR+LF sent to the printer?  PCL in general
>will normally ignore those characters so at best you're doing no harm, at worst
>you're corrupting the data.
>
>>    SwapVectors;
>>    Exec (GetEnv ('COMSPEC'), '/C COPY FONT1.FOO PRN > NUL')
>>    SwapVectors;
>
>Off the top of my head try:
>    
>     Exec( GetnEnv('COMSPEC'), '/C copy/b font1.foo prn > nul');
>

I posted a similar question a few days ago, but got no responses, so maybe
the post didn't get through. I am using Turbo Pascal 5.5, and when I execute
a command sequence as above, my computer HANGS COMPLETELY. But: not on every
computer, and only WHEN I RUN FROM A DIRECTORY PATH MORE THAN 20 CHARS
LONG! In my case, I used a $M-directive that forced a DosError=8, by 
applying $M 4000,0,655360. The fact that the program of the original poster
did not run, might of course be a $M-problem. When there IS a problem with
the Exec-call, as I suggested in my original post, more trouble can be
expected.

>
>Sounds like a DOS bug to me.  If you're using the EXEC command to call the copy
>command.  Is there any correlation between DOS versions and/or IBM-DOS vs
>MS-DOS?  It sounds to me like sometimes the ^Z's are causing problems and 
>sometimes they aren't  (at least off the top of my head :-)

In the code where I had a problem, the problem persisted under MSDOS 3.1, 3.3
and 4.01. But: not on every computer, dependent on the place in memory where
it is executed, and only from a long directory path!

For completeness, I include the text of the original post I sent out a few
days ago. IS ANYONE ELSE EXPERIENCING THE SAME PROBLEMS (COMPUTER LOCKING UP
WHEN EXECUTING THE CODE BELOW, NOT GIVING A DOSERROR=8, WHEN RUNNING THE
.EXE-FILE FROM A DIRECTORY PATH WITH MORE THAN 20 CHARACTERS??????)

Post from a few days ago:

I have a very strange problem using the EXEC-procedure under
Turbo Pascal 5.0. The problem is that the computer locks sometimes
when executing the Exec-call. At first, the problem occurred when
using an Exec after a heap-compress, and I thought the problem was
with the heap-compression procedure, and not with the Exec-call.
I could, however, reproduce part of the error with a very small
Turbo Pascal program that does not compress the heap.

The program is as follows (and YES, I KNOW it should not run!)

------------------------------------------------------------------------
program testmswp;
{$M $4000,0,655360}

uses Crt, Dos;

procedure ItemFileEdit;

var
  DosErrorCode : word;

begin
  SwapVectors;
  Exec(GetEnv('COMSPEC'),'/C MS-WP.EXE item.txt');
  SwapVectors;    { The above ^ program does not exist. No problem }
  if DosError<>0 then
    writeln('EXEC ERROR NUMBER ',DosError);
end;

begin
  ItemFileEdit;
end.
------------------------------------------------------------------------

The program does not have enough memory to execute, and therefore a
DosError=8 should occur. This happens in most cases. When I run this
program from a directory with a pathname longer than 20 characters, 
the computer locks up, violates CMOS Setup memory, and does other
strange things. So:

   C:\TEST> testmsw2 [Enter]  works fine, but
   C:\TESTTEST.TST\TESTTEST.TST> testmswp [Enter] locks up the computer...

I am not sure it behaves this way on ALL types of computers and versions
of MSDOS. I tested it on three different types of AT and 386 computers,
running MSDOS 4.01, 3.1 and 3.3. It behaved in the same strange way on
ALL three computers.

When running it under the Turbo Debugger, the problem does NOT occur.
When running it under TD386, the debugger locks after performing the
Exec. I also got an 'Exception 12, Error 0' once.
When loading one or two extra versions of COMMAND.COM, the problem does not
occur, so I think it only happens using the primary copy of MSDOS, which
is the one that was loaded during the boot process. 

HELP! Does anyone know what is happening? The program should generate a
DosError=8, independent from the directory it was called from!

>
>Scott Bostater      Georgia Tech Research Institute - Radar Systems Analysis
>"My soul finds rest in God alone; my salvation comes from Him"  -Ps 62.1
>uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!bb16
>Internet: bb16@prism.gatech.edu

-------------------------------------------------------------------------
Alexander Verbraeck                    e-mail: winfave@duticai.tudelft.nl
Delft University of Technology                 winfave@hdetud1.bitnet
Department of Information Systems              winfave@duticai.uucp
PO Box 356, 2600 AJ  The Netherlands           winfave@dutrun.tudelft.nl
Tel: +31 15 783805  Fax: +31 15 786632/787022  winfave@dutrun.uucp
-------------------------------------------------------------------------