Path: utzoo!attcan!uunet!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!jaytee!hiredgun!tdinger From: tdinger@hiredgun.East.Sun.COM (Tom Dinger - Sun BOS SPA) Newsgroups: comp.lang.perl Subject: Re: Proposed enhancements to MS-DOS perl Summary: Already done some enhancements Message-ID: <2764@jaytee.East.Sun.COM> Date: 29 Sep 90 02:31:32 GMT References: <1990Sep20.013320.9162@holos0.uucp> Sender: news@jaytee.East.Sun.COM Reply-To: tdinger@east.sun.com (Tom Dinger - Sun BOS SPA) Followup-To: comp.lang.perl Organization: Sun Microsystems, Billerica MA Lines: 178 I have already done a bunch of the things you mentioned in the following: In article <1990Sep20.013320.9162@holos0.uucp> lbr@holos0.uucp (Len Reed) writes: >I'm planning on make several important enhancements to the MS-DOS >version of perl. I'd appreciate knowing about any problems, >ideas, or applicable code anyone may have. > >1) Fix up the test scripts to work under MS-DOS. Most do > already. Those that don't typically do one of the > following: > a) Attempt to access an illegal DOS file name. For > example, open(HANDLE, ">This.file.tmp"); There's no > reason that both Unix and MS-DOS couldn't use the same, > shorter name. > b) Doing something that MS-DOS can't do, like forking. > c) Using a Unixism, like "/bin/rm". I have modified many (most?) of the scripts, that weren't hopelessly mired in **ix-isms. For example, many of the io.* scripts did not seem easy to "translate." The ones that I have had problems with are: comp.cpp (C pre-processor is is no fixed DOS place) io.* (seem to be **ix-dependent) op.fork (no fork() under DOS) op.goto (??? can't find my notes on this one) op.magic (DOS DIR command incompatible with **ix ls command) op.split (??? no notes here either) op.stat (lots of differences, mostly due to handling of file time under DOS) op.times (I used a "no-op" times() function). The rest of the scripts (renamed) run, and I believe almost all tests pass. > >2) Minor bug corrections. The program should pass as much of > the test suite as possible under DOS. I have found and fixed a bunch of bugs: 1. I "fixed" some of the #includes in perl.h to include more of the Microsoft headers. 2. I added a dummy times() function -- none was supplied with the DOS perl support files. 3. I cleaned up use of the symbols FCNTL and I_FCNTL -- in the sources and Configure script, they were effectively identical and interchangable. I changed things so that I_FCNTL means "the file should be #included" (MSC has that file), and FCNTL means "the fcntl() function is available, use it" (MSC does not have that function). 4. You need a file to satisfy the #includes, but it can be empty. > >3) Better determine where optimization fails and selectively > turn off specific optimizer switches as needed. I did this -- I can now compile all the sources using -Ox (full optimization, including loop optimization.) This turned up a (known) bug in MSC's loop optimization (found in array.c) that caused the unshift test (I think) to crash perl. In addition it turned up a previously unknown bug (to me that is) in the more "normal" -Os or -Ot optimizations, that caused incorrect code to be generated within regcomp.c, causing regexp tests 73 and 115 to fail. I have a 4-page write-up of this bug, if anyone's interested. > >4) Swapping while running a subprocess. Since 640K isn't much > when you're running perl, it would be nice to have perl swap > itself out when doing subprocesses. Fortunately, I have > already modified one program to do this, so it'll just mean > hooking perl to run that code. First, the good news: I have a _drop-in replacement_ for the MSC lowest-level spawn functions, that will permit swapping to EMS, XMS or DISK, by default, without _any_ source code changes (link with an OBJect file and a library). Add one line of C (define a global variable) and you can control in which order it will try the different swap targets, with an environment variable of your own naming. When perl (or any program using spawn*()) is swapped, it uses only 2460 bytes, plus a copy of the child`s environment, plus its own environment (total: about 3K bytes). Pretty good for a 300K+ program. Now the bad news: currently, though I wrote the code, it belongs to my company, and my partner and I are still discussing what we want to do with it. (I wrote it for a "make" program I wrote for our company). So I have not (yet) distributed either the binaries or sources. I have only had the code working for about three weeks, so it may yet see the light of day. > >5) Complete MKS compatibility (see below for a plug for MKS). > I don't usually modify free software to have full MKS > compatibility, but perl is an obvious case for such > treatment. I have parts of this lying around from other > work. > a) Accept 8 K-bytes of arguments as per MKS conventions, > so that Korn shell commands like "perl script *.c" work > even if there are a lot of c files. > b) Pass extended argument list to sub processes. > c) Run Korn shell instead of command.com to do > subprocesses when a shell is needed, handling > metacharacter set properly. > d) Run MKS glob.exe to do globbing of things like . > e) Handle "switch" character properly. (Currently > perl.exe will run "command /c the_command" instead of > "command -c the_command" when the switch character is a > hyphen instead of a slash. > f) Continue to work as well as can be expected if MKS tool > kit is not present. I.e., the enhancements shouldn't > mess anything up. PLEASE make this optional (I noted in later postings that you intend to do so.) I do not use MKS, nor am I about to start; however, I would welcome a "reasonable" standard for supplying long command lines to applications, as long as it is backward-compatible with applications that know nothing about it (lots of them). Other things I have done to perl [the audience gasps]: 1. As many DOS-perl users will not be compiling perl for their own system, and additionally because DOS users must contend with drive letters, I have added to _all_ versions of perl (not just DOS) the ability to use the PERLLIB environment variable as the path on which to find the perl "library." 2. Patch 19 changed stab.c to use the setuid() function "unguarded". Patch 21 changed doarg.c to use both setuid() and setgid() functions. I added two symbols: SETUID and SETGID, and guarded those function calls with them, so that they could be disabled for DOS. 3. I added the OS/2 add_suffix() routine to the DOS version (great stuff!) 4. I added use of the TMP environment variable for the perl -e option, to create the temporary input script. Rationale was the same as for PERLLIB, plus it is a quasi-standard in the DOS world. In the on-deck circle: 1. Using a custom chdir() function for DOS, that will change the drive as well as the path if a drive is present. For example: chdir("\\"); /* change to root of the current drive */ chdir("D:"); /* change to drive D, whatever the current directory*/ chdir("E:\\"); /* change to drive D, change it's current dir to root*/ etc. No new functions in perl are needed; everything you need to do under DOS is avaiable. 2. Finish converting the test scripts to work under DOS. 3. [Just a thought] MSC provides enough information and hooks in the start-up code to replace the ARGV processing -- we could produce a command-line parser that would handle quoted arguments "smarter" and could glob, like the command-line processing the DOS shell recently made available. >-- >Len Reed >Holos Software, Inc. >Voice: (404) 496-1358 >UUCP: ...!gatech!holos0!lbr I intend to make all the changes I made to perl available Real Soon Now. Acknowledgements: Thanks to Larry, for a terrific tool, and portable to many platforms; Thanks to Diomidis Spinellis, for the lion's share of the work in the DOS port; Thanks to all of the other Perl Hackers and Enhancers, for bug fixes and porting work; Thanks to Len for offering to do the work, and spurring me on to go public; I'd like to thank my agent, and my parents, and everybody I've ever met... TD ---------- Tom Dinger consulting at: TechnoLogics, Inc. Sun Microsystems Internet: tdinger@East.Sun.COM (508)486-8500 (508)671-0521 UUCP: ...!sun!suneast!tdinger Tom Dinger consulting at: TechnoLogics, Inc. Sun Microsystems Internet: tdinger@East.Sun.COM (508)486-8500 (508)671-0521 UUCP: ...!sun!suneast!tdinger