Of course I immediately tried to build Python. The good news is that
most source files compiled without a hitch after I had determined the
proper contents of config.h. This took about one afternoon (including
learning how to use the compiler environment). I postponed
implementing a few system calls (e.g. sleep()) properly until a later
date but other than that there were no real problems.
Then the testing began, and I found the real problem with Python for
DOS: IT IS TOO BIG. A simple statement like "import string" caused a
MemoryError in the parser. I decided to put a little test in the main
program to find out how much memory was actually available to malloc()
and found that there was only about 88 kbyte free. My hypothesis
(based upon very limited understanding of DOS) is that malloc() is
limited to the 640 kbyte that DOS gives you at most, less the size of
the program text, the operating system, and other overhead factors.
I have tried several memory models (Large and Huge) with essentially
the same results. (I tried it in the Windows DOS-prompt as well as in
DOS without having windows around.) I suppose I could squeeze maybe
100 kbytes out by throwing out some little-used built-in modules and
telling the optimizer to optimize code size, but it doesn't seem like
this would help much: a reasonably-sized Python program would still
run out of memory pretty quickly.
I am now considering to support Python on the PC for Windows only.
Using the Microsoft QuickWin library I have found that it is trivial
to create a Python executable that (a) behaves like a standard Windows
application (with a single text window where the prompt appears to
which you can type interactive Python statements) and (b) can allocate
essentially all the memory the machine has (though if you ask for the
last few bytes it may run infinitely slow). This sounds like a useful
thing to me, and it's very little work.
However, I don't know what the majority of PC users would like, and,
not being a DOC hack myself, I also don't know if maybe there is a way
to use the extended memory that's obviously sitting *somewhere* in the
machine. Given the structure of Python's code, this would have to be
compatible with the standard malloc() function, somehow.
If you are a DOS or Windows user or programmer, please let me know
what you want. Would you prefer a DOS version with limited
capabilities over a Windows version? Would you use a Windows version
at all? Is there something I have overlooked or simply don't know
about yet?
In any case I will make the Windos version of Python available on the
ftp site within a few days -- there seems little use in delaying that.
Cheers,
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>