📄 ch16.htm
字号:
things that you learn about the language itself will give you
a jump start if you ever decide to go to a different environment.
No matter where you end up programming, chances are very good
that some variant of Perl will be there to make life easier.
<H4>Getting a Copy</H4>
<P>
Finding Perl for DOS can be hard. With version 5 of Perl storming
out the gates and the mass migration to 32-bit platforms, the
availability of a Perl 5 port for DOS is a very slim possibility.
You can still find archives of Perl 4.036 for DOS by searching,
but the sites that keep it in storage areas are getting fewer
and farther between. At the time of writing the only site with
an accessible copy of Perl 4.036 for MS-DOS was: <TT><FONT FACE="Courier"><A HREF="ftp://ftp.ee.umanitoba.ca/pub/msdos/perl">ftp://ftp.ee.umanitoba.ca/pub/msdos/perl</A></FONT></TT>.
Others may appear, so if you have problems with the above address,
try a general search on "dos perl" on any of the major
Web search engines.
<H4>Problems</H4>
<P>
Because Perl is an interpreted language that's not native to DOS,
every time you go to run your Perl script, you have to start up
a copy of PERL.EXE to do the interpreting. As you would expect,
running this file sucks up more memory and slows down the process.
This slowdown is one of the trade-offs you make for the additional
power. Perl is also a more robust programming language and thus
requires more of a learning curve to get it to do all the things
you want it to do because it has so many more capabilities.
<P>
Another problem is that some of the Perl scripts and Perl libraries
available are UNIX-centric. This means that if you see something
really useful that you want to place on your site, you may have
to do some significant tweaking to get it to work right, if there's
any chance of it working at all. Remember, just because the Perl
script thinks it can do the job doesn't mean that DOS is up to
the challenge.
<H4>Example: Storing Forms Output</H4>
<P>
To continue with the trend of examples, look at the same form
data storage routine created in Perl for DOS, as shown in Listing
16.5. As you can see, it has some equally strange commands if
you're not used to it, but it's much better suited for this kind
of task (because it takes care of splitting text strings based
on special characters), and you don't need a compiler to run it.
<HR>
<BLOCKQUOTE>
<B>Listing 16.5. Storing form data using Perl for DOS.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier"># Basic DOS CGI Form Handler, in Perl
<BR>
# Bill Schongar, July 1996<BR>
<BR>
# First, open file for data<BR>
$content=$ENV{'CONTENT_FILE'};<BR>
open(IncOMING,$content);<BR>
<BR>
# Put all data from the file into one variable<BR>
while (<IncOMING>) {<BR>
$data=$data.$_;
<BR>
}<BR>
close IncOMING;<BR>
<BR>
# Now break the data up into the three components<BR>
# -First by the & sign, to separate pairs<BR>
# -Next by the = sign, to split name and value<BR>
($a,$b,$c) = split(/&/,$data);<BR>
($junk,$first) = split(/=/,$a);<BR>
($junk,$last) = split(/=/,$b);<BR>
($junk,$email) = split(/=/,$c);<BR>
<BR>
# Now send some output<BR>
# -All print statements get redirected to OUTGOING,<BR>
# which is the OUTPUT_FILE<BR>
$output=$ENV{'OUTPUT_FILE'};<BR>
open(OUTGOING,">>$output");<BR>
print OUTGOING "Content-type: text/html \n\n";<BR>
print OUTGOING "<title>Input Received</title>
<br>\n";<BR>
print OUTGOING "Thanks for giving us the information, $first.
\n";<BR>
print OUTGOING "We'll send you some email later... \n";
<BR>
close OUTGOING;<BR>
<BR>
# Now store it all to a file<BR>
$store="c:\\temp\\storeme.txt";<BR>
open(STORAGE,">>$store");<BR>
print STORAGE "************ \n";<BR>
print STORAGE "Visitor Data \n";<BR>
print STORAGE "Name: $first $last \n";<BR>
print STORAGE "Email: $email \n";<BR>
close STORAGE;</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
This program results in much cleaner output, with much less work
for everyone.
<H3><A NAME="cc">C/C++</A></H3>
<P>
The top of the line for DOS CGI power and performance is C or
C++. A compiled C/C++ executable (.EXE) doesn't need any outside
help to be interpreted, it can do anything you could possibly
want it to (with the exception of making DOS more efficient),
and it's lightning fast. The disadvantage is that it's not easy,
and as a result using C/C++ takes a lot more work to get the results
you want.
<P>
If what you want is complex or really cool, then using C/C++ might
be worth all the extra work. If you're absolutely desperate for
performance, then you might consider using C/C++ for even basic
operations, like the form dump you've been looking at in both
BAT and Perl implementations. Be forewarned, however; doing the
same amount of work takes a lot more effort, and saving the effort
for something that you just can't do easier with something else
is normally better.
<P>
To use C/C++, you first need a C compiler. If it's a couple years
old really doesn't matter, as long as it produces good command-line
runnable code. For instance, Visual C++ 1.0 is horrendously out
of date, but you can find it for next to nothing (you can sometimes
find it in books on C++ programming), and it produces fully working
code. Being able to use older compilers is a definite benefit
when you consider that you would end up spending several hundred
dollars on a current copy of Visual C++ or any other well-known
compiler.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
If you use Visual C++ or any other Windows-based compiler, be absolutely sure that you create your project as a command-line application, with no windows, no message boxes, and no real need of Windows controls. DOS CGI is somewhat limited in what it will
do to let you communicate in its little shell, and you have to be kind to it.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
Using C as your programming language of choice opens up every
possibility that DOS has to offer, and it also makes life very
complex. Unless you've programmed in C before or really need to
get the functionality, you might want to hold off until you've
had a chance to play with C before you jump head first into DOS
CGI programming with it. Because C is not a scripting language,
you have to recompile each time you change something, and if you're
just learning, recompiling is going to add up to a lot of time.
After you learn the basics of file input/output and string handling,
though, you've got enough knowledge to at least make a starting
run at programming.
<P>
For implementation, C programming structure is much more like
Perl or QBasic than the BAT methodology. You can use C's built-in
functions to save overhead instead of running to external processes
and dragging the system down too far.
<H2><A NAME="Limitations"><FONT SIZE=5 COLOR=#FF0000>Limitations</FONT></A>
</H2>
<P>
People often shun DOS CGI because it's limited in how much it
can do-not necessarily functionality wise, but just the amount
of effort it dedicates to each task you want to perform. When
you run a DOS CGI program, DOS has to allocate a certain region
of resources to that particular processing task. This virtual
machine (VM) puts a hard limit on just how many processes you
can have running at once before you fill up environment space
and memory, and DOS grinds to a halt because it's trying to pretend
it can multitask. If what you're running is small and efficient
and is over quickly, you may not have a problem. If what you're
running is big and inefficient, like a huge QBasic program or
Perl script, you've got a problem.
<P>
Most likely, you will never find a server that performs intense
DOS CGI activity and survives for long. If you're running a personal
Web site and expect a couple hundred hits per day, and maybe 10
percent of those folks will execute CGI requests, you don't really
have a problem. Your site may be slower than some other sites,
but that kind of load won't crush DOS CGI. If you're running a
high-traffic or CGI-intense site (with internal CGI counters on
every page, dynamic page creation, and so on), however, DOS CGI
won't keep you afloat. I'm not saying that it doesn't want to,
but there's a limit to how many processes it can spawn at once.
<P>
One of the speed problems is caused by the extra file input and
output used for <TT><FONT FACE="Courier">CONTENT_FILE</FONT></TT>
and <TT><FONT FACE="Courier">OUTPUT_FILE</FONT></TT>. Although
memory buffers are fast, disk access isn't, especially if a lot
of output is being written out. In addition, when you start reading
in files left and right or processing them, more memory is taken
up. You can reduce this problem by having a fast hard drive and
lots of available memory, but the underlying drag will still be
present no matter what you do.
<P>
As for functionality limitations, you're only up against what
DOS can and cannot support in any language available to it. You
have many options, as long as load isn't going to be an issue.
But what happens when a function just isn't available, or you
don't have the time or expertise to implement it in the language
that supports it? Sometimes you need to dig further, and look
at all the resources available to you.
<H2><A NAME="Resources"><FONT SIZE=5 COLOR=#FF0000>Resources</FONT></A>
</H2>
<P>
If you've ever done a general search on any Web search engine,
looking for information on DOS CGI, chances are you were disappointed
by what you found. With the biggest segments of the Web server
population on UNIX and 32-bit Windows, DOS doesn't get very many
devotees. The other reason that you don't see too much on DOS
is that DOS CGI programming, with the basic exceptions and limitations
I've outlined, is just like programming for any other platform.
All you have to know is how to modify things for your own use.
<H3><A NAME="ConvertingOtherCGIProgramsandInform">Converting Other
CGI Programs and Information</A></H3>
<P>
To convert CGI programs, here's the first rule of thumb: where
you see STDIN, think <TT><FONT FACE="Courier">CONTENT_FILE</FONT></TT>;
where you see STDOUT, think <TT><FONT FACE="Courier">OUTPUT_FILE</FONT></TT>.
To see some of these variables, you really need to know a little
bit about the languages and how they point to these variables.
You can easily check for <TT><FONT FACE="Courier">print</FONT></TT>
statements of any kind (<TT><FONT FACE="Courier">print</FONT></TT>,
<TT><FONT FACE="Courier">printf</FONT></TT>, and so on). Normally,
these statements either point to a file handle, such as <TT><FONT FACE="Courier">print
MYFILE "Some text here \n";</FONT></TT> in Perl or <TT><FONT FACE="Courier">printf(MYFILE,"Some
text here");</FONT></TT> in C, or they point nowhere, such
as <TT><FONT FACE="Courier">print "Some text here \n";</FONT></TT>
in Perl. These <TT><FONT FACE="Courier">print</FONT></TT> statements
that go nowhere are almost always pointing to STDOUT, so you need
to identify them and aim them back at <TT><FONT FACE="Courier">OUTPUT_FILE</FONT></TT>.
If these statements are already pointing to a file, chances are,
they're using it for general storage, so you can keep them just
the way they are and even use the file handle there originally.
<P>
Here's the second rule of thumb: Be sure DOS (and the language
you intended to use) supports the functionality you're trying
to use. If you see anything like <TT><FONT FACE="Courier">ls</FONT></TT>,
<TT><FONT FACE="Courier">rsh</FONT></TT>, or <TT><FONT FACE="Courier">grep</FONT></TT>,
back away slowly. They are UNIX system commands, and only some
of them have built-in equivalents on the DOS side. The easiest
translation to is to change <TT><FONT FACE="Courier">ls</FONT></TT>
to a <TT><FONT FACE="Courier">dir</FONT></TT> command, with possibly
one or two other command-line parameters. But remember that many
scripts are UNIX-centric and bear careful watching before you
try to convert them over. If you don't recognize a command, type
the command, followed by a space, a forward slash, and a question
mark (<TT><FONT FACE="Courier">/?</FONT></TT>), and see if any
information comes up on it in DOS. If the system has no idea what
you're talking about, you've hit a UNIX command.
<P>
Information that's available on CGI, any information, is valuable.
It's not called the Common Gateway Interface just for fun-over
90 percent of what you see and read holds true to every platform,
when taken in its most general sense. Everyone uses environment
variables in one way or another. Headers don't change just because
you're on a different system, and HTML code is still HTML code.
<H3><A NAME="WebServerSoftware">Web Server Software</A></H3>
<P>
Good Web server software normally comes with a whole host of examples.
For servers that support DOS CGI, this fact holds true as well.
WinHTTPD contains several examples of batch files taking care
of basic CGI tasks. You can use any one of them as a comparison
to make sure that you're doing things right after you get going.
Depending on your server software, additional tricks or features
may be added in to make your life easier. Or you may find documentation
about what to (or not to) do to get DOS CGI going. Be sure to
look through all of it-you never know when two minutes of searching
will save you two hours of frustration.
<H3><A NAME="DOSProgrammingBooks">DOS Programming Books</A></H3>
<P>
Chances are, you won't see as many books on the shelves of your
favorite book store that deal with DOS programming nowadays as
you would with just about any other topic. But basic references
are still there. Many game companies still deal with DOS first,
to avoid Windows overhead-and the folks who wrote DOOM certainly
didn't create it using BAT files.
<P>
You should look for references that give you information that
you need. DOS may seem limited, but people have made some pretty
powerful applications in it over the years, and when it is used
correctly (and with the right software), it can perform most any
task, from dialing a modem to printing out user requests to accessing
databases. You don't want information that deals with graphic
interfaces unless you're planning to print out special information
through another port to a printer or fax. You're really should
be interested in C programming books that deal with communications
and general data processing. Sometimes the public library is the
last place you might expect to find the information you're looking
for in the computer field-because most of the books are older
than you need-in this case, however, the library should have information
just about the right age for you to find what you're looking for.
Sometimes time lags work in your favor.
<H2><A NAME="Summary"><FONT SIZE=5 COLOR=#FF0000>Summary</FONT></A>
</H2>
<P>
If you're using DOS CGI, chances are you don't have a choice.
Using DOS does place limits on how much space you can take up,
what built-in functions are available, and just generally how
far it'll do what you want it to, with all that extra file input
and output. But don't give in to despair. Remember, DOS programs
have been flourishing for years, and plenty of power and functionality
is available out there; you can take advantage of it if you know
where to look.
<P>
<HR WIDTH="100%"></P>
<CENTER><P><A HREF="ch15.htm"><IMG SRC="pc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="#CONTENTS"><IMG SRC="cc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="index.htm"><IMG SRC="hb.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="ch17.htm"><IMG
SRC="nc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A></P></CENTER>
<P>
<HR WIDTH="100%"></P>
</BODY>
</HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -