[comp.lang.perl] Progress on MS-DOS Enhancements

lbr@holos0.uucp (Len Reed) (09/30/90)

First things first.  It appears that the local uucp maps got
messed up and we haven't been receiving e-mail for about a week. 
If you have written me and have not received a reply, I probably
didn't get it.  The problem has been fixed, so please try again.

Work on MS-DOS perl 3.0, patch level 28 has been progressing
well.  My version now swaps itself to disk (all but <2K) when
running subprocesses.  Various minor and one major problem with
"pipes" and subprocesses have been fixed.

Perl.exe now is fully MKS compatible for incoming argument and
for spawned subprocesses.  If you have the MKS tools, you can
pass it very long pre-globbed command lines, and will invoke the
MKS glob program to expand wild cards if run from a non-MKS
program.  Perl will run compatible tools (including itself) as
subprocesses, passing out large argument lists.  Incompatible
tools are unaffected, though of course they only see the niddling
128 byte "command tail."  The Korn shell is used for expanding
things like <*.c>.

If you don't have the MKS tools, perl.exe will run the Microsoft
library code to expand wildcards, using the DOS rather than the
Unix ideas about globbing.  It will allow double quotes, so you
can use perl's -e mechanism.  The supplied globbing program is
still used for <*.c>.

I've gone to some trouble to allow environment variable control
over where the swap file goes and what kind of globbing and
subprocess invocation is used.  The scheme should be general
enough to allow MKS users, bare-bones DOS users, and other shell
users (4DOS, etc.) to use the same perl.exe.  Obviously the
greatest degree of Unix-like behavior will be when using the MKS
Korn shell.

Yet to do:

I want to get the exec mechanism working as well as subprocesses. 
I've been reworking the test scripts (where necessary) so that I
hope to get the program to pass every test that is feasible. 
(I'm not going to make forks work. :-))  I haven't looked into
using the -P switch; ideally this should work with at least Turbo
as well as Microsoft. I haven't yet turned on the optimizer; when
I do that I'm sure there will be a few problems.

About the code:

The DOS port by Diomidis Spinellis was specific to Microsoft C
5.x.  My extensions are even more Microsoft C specific since they
hook the startup logic and use intimate knowledge of where the
compiler and linker put things when swapping.  Of course I
will post the executable as well as the source.
-- 
Len Reed
Holos Software, Inc.
Voice: (404) 496-1358
UUCP: ...!gatech!holos0!lbr

markb@agora.uucp (Mark Biggar) (10/01/90)

In article <1990Sep30.021358.17543@holos0.uucp> lbr@holos0.uucp (Len Reed) writes:
>using the -P switch; ideally this should work with at least Turbo
>and Microsoft.

I worked on this for a while and finaly gave up.  Two major reasons:  There is
no way to invoke that Microsoft preprocessor in such a way that it read its
input for the standard input.  I eventually bit the bullet and used a temp file.The second insurmountable problem is the the Microsoft perprocessor assumes that
its input can be tokenized as a legal C program.  It goes absolutely crazy over
perl code complaining about back-ticks, @ signs and other Non-C syntax.

--
Perl's maternal uncle
Mark Biggar