Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umd5!jonnyg
From: jonnyg@umd5.umd.edu (Jon Greenblatt)
Newsgroups: comp.windows.ms
Subject: Re: Has anyone seen this problem.....
Keywords: System incompatability!
Message-ID: <4533@umd5.umd.edu>
Date: 16 Feb 89 18:37:47 GMT
References: <4517@umd5.umd.edu> <10731@well.UUCP>
Reply-To: jonnyg@umd5.umd.edu (Jon Greenblatt)
Distribution: usa
Organization: University of Maryland, College Park
Lines: 58

In article <10731@well.UUCP> brent@well.UUCP (Brent Southard) writes:
>In article <4517@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes:
>>	I am stumped! I am porting a lisp interpreter (xlisp2.0) to
>>MS Windows. I am using an internal memory allocation routine that breaks
>>memory off of large blocks of GLOBAL FIXED memory. The program is

	.......

>Bad move.  I'm sure you've been told this before, but I reiterate:  don't
>keep global memory locked in Windows.  Windows is CONSTANTLY moving code and
>data segments around.  Even a few small locked segments can bring the
>machine to a virtual standstill if conditions are right.  I realize this

	.......

	My problem was do to a programming error but I would like to comment
about my experiences thus far with global memory. First of all xlisp 2.0
is written in such a way that makes it extreamly hard to port to the
medium memory model. I realy feel it is hard to port just about any large
program that uses a lot of memory to MS Windows when the code was not written
around MS Windows. Try passing a long string pointer to printf in the medium
model for instance. This goes back to a point I like to make that apps cannot
realy be portable to MS Windows unless written for MS Windows! I have no plans
to make xlisp 2.0 work in the medium model for several reasons:

	1: The pointer conversions will make the code unreadable and
	   unsuportable.

	2: The code needs to be portable to other operating systems. Half
	   the base system coding in the medium model would be MS Windows
	   dependent. Right now very little code is dependent on any operating
	   system.

	3: The fact that Actor has not done any better with their highly
	   system dependent implementation of a dynamic language leads
	   me to believe there is little hope for dynamic languages under
	   MS Windows. Actor promised a virtual memory system but I have not
	   seen it. I thought about making xlisp dynamic but the paging would
	   get overly extensive.

    Actor uses more fixed memory than my xlisp interpreter. Even though Actor
unlocks this memory when not in use you cannot run any other windows programs
of any size in most cases. Just becuase you unlock something does not make it
take less windows memory. BTW Actor uses one code segment so they seem to be
using near function calls.

	I am not trying to flame Actor, it runs much faster and is much
more extensive than Xlisp. I am just trying to point out how hopeless writing
a dynamic laguage that follows all the rules of MS Windows can be. My final
version of the lisp interpreter will unlock the segments when not in use but
this has marginal if any benefit the way the MS Windows memory manager is
written to date! I usualy start xlisp before running other apps, this solves
most of the fixed memory problems when interacting with the heap.

	I do plan to "toy" with using Movable/Virtual memory in xlisp but this
will slow things down. The large model is here to stay!

						JonnyG.