Good development platform, I suppose... but a far cry from the 80186 at
8MHz, 640k main memory (with anything between 380k and 10M of
solid-state hard disk space) Hewlett-Packard 100LX Palmtop that some of
us (a handful really) hoped to use Python on! :-)
>Then the testing began, and I found the real problem with Python for
>DOS: IT IS TOO BIG.
As I recall this was one the problems I encountered with the previous
DOS port of Python, but the main one was by far the overall slowness of
things.
>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.
Things have worsened, then. It used to have something like 300k with
the previous port (speaking from memory [no pun] there).
>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.
Correct. Depending on the memory model other limitations can creep in,
of course.
>I am now considering to support Python on the PC for Windows only.
Obviously, this will be no help for us people with palmtops (did I
forget to mention that these Machines do not run Windows? You had
probably guessed it anyway). But there may be a market for a Windows
only Python (last minute: I just saw a post to this effect, so here you
go)
>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.
There probably isn't such a thing a "the majority of PC users"... As
far as shoe-horning extended memory into the usual malloc() model is
concerned it's a nightmare. All sorts of limitations still apply (like
the maximum size of a chunk you can malloc(), since extended memory has
to be mapped into the first megabyte of address space when you access
it).
As someone already mentionned some time ago, the only way to go is
probably to use a so-called "DOS-extender", i.e. use the processor (>=
386) as a real 32-bit processor, and not in the usual brain-dead Intel
8086 mode. How much work does that require? I don't know, not being
much of a DOS hacker myself (but I have done a good deal of 80386
programming, hence these remarks)
>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?
For us palmtop users: DOS with limited capabilities. Others will want
something else, of course. But you did ask, didn't you? :-)
Cheers,
Olivier Boulot France Telecom / CNET olivier.boulot@issy.cnet.fr