home *** CD-ROM | disk | FTP | other *** search
- id m0u9Xmh-0007rfa; Wed, 17 Apr 96 08:00 MDT
- Sender: owner-executor
- Received: by ftp.ardi.com (Smail3.1.29.1 #3)
- id m0u9Xl2-0007rsC; Wed, 17 Apr 96 07:58 MDT
- Received: by gwar.ardi.com (Smail3.1.29.1 #3)
- References: <199604170141.SAA28165@dfw-ix12.ix.netcom.com>
- Message-id: <m0u9Xj9-000GPQC@gwar.ardi.com>
- Subject: Re: FW: Let's get System 7.x on top!
- Cc: "executor@ardi.com" <executor@ardi.com>
- In-reply-to: <199604170141.SAA28165@dfw-ix12.ix.netcom.com>
- To: "Dan Guisinger" <dan_g@ix.netcom.com>
- Date: Wed, 17 Apr 96 07:56 MDT
- From: mat@ardi.com (Mat Hostetter)
- Sender: owner-executor@ardi.com
- Precedence: bulk
-
- >>>>> "Dan" == Dan Guisinger <dan_g@ix.netcom.com> writes:
-
- Dan> 10) Virtual Memory -- Executor currently has the limit of NO
- Dan> virtual memory. Win95 has an dynamic swap file that
- Dan> grows/shrinks with use. Executor can report the maxinum
- Dan> amount of memory a 68040 (and in the future, PPC) can handle,
- Dan> and thus no memory problems.
-
- Actually, since Executor is a DPMI client it *does* use virtual
- memory...I've run Executor on an old laptop with 4M of RAM just fine
- (it was of course paging).
-
- However, from what I've seen it appears to be the case that there are
- advantages to allocating memory through the Win32 API, rather than
- through the DPMI API.
-
- -Mat
-
-