Xref: utzoo comp.windows.ms:13391 comp.windows.ms.programmer:2845 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!fernwood!uupsi!sunic!fuug!fuug.fi!pena From: pena@brainware.fi (Olli-Matti Penttinen) Newsgroups: comp.windows.ms,comp.windows.ms.programmer Subject: Re: Over 16 Meg Message-ID: Date: 3 Jun 91 12:36:48 GMT References: <1991May30.174414.19047@midway.uchicago.edu> <1991May30.000945.12529@xanadu.com> <1991May31.012439.4019@ux1.cso.uiuc.edu> <1190@tuura.UUCP> Sender: usenet@fuug.fi (USENET News System) Organization: Brainware Oy, Espoo, Finland. Lines: 43 In-Reply-To: risto@tuura.UUCP's message of 3 Jun 91 06: 47:35 GMT Nntp-Posting-Host: brainw.brainware.fi In article <1190@tuura.UUCP> risto@tuura.UUCP (Risto Lankinen) writes: >>>Has anyone had any success at all trying to get Windows 3.0 Enhanced >>>Mode to recognize the existence of over 16 Mb of RAM? I have 32 Mb of >> >>Windows is still more or less a 286 app, with segments and 24-bit addressing, >>and shouldn't be able to directly access 32 Mb of RAM. Nothing designed to >>run on a 286 can use more than 16 Mb of extended memory. >I do not understand this. In 386 enhanced mode, Windows 3.0 uses virtual >8086 mode for DOS programs. It should be able to run those above 16 megs. >Does it? Hi! I don't have the hardware, so I can't check it out, but how is it with the EISA or MCA buses? Doesn't the AT-bus have 24 address pins only, so that there's no 'standard' way to access the memory above 2^24, even if the CPU were capable of addressing a greater amount of memory? The way to go, in addition to having CPU >= 386 , would be to increase the number of address pins, which both EISA and MCA do. As said, I'm only guessing... can anyone confirm? Terveisin: Risto Lankinen -- Risto Lankinen / product specialist *************************************** Nokia Data Systems, Technology Dept * 2 3 * THIS SPACE INTENTIONALLY LEFT BLANK * 2 +1 is PRIME! Now working on 2 -1 * replies: risto@yj.data.nokia.fi *************************************** Yes, that exactly is the case. BTW, the same problem occurs with all Unix implementations for ISA bus machines, as well. One possible way of (partially) solving the problem is to let each task own max. 16 MB and let the MMU logic take care of the rest. Inherently machine dependent and doesn't work with Windows, of course :-) ==pena -- Olli-Matti Penttinen | "When in doubt, use brute force." Brainware Oy | --Ken Thompson P.O.Box 330 +---------------------------------- 02151 ESPOO, Finland Tel. +358 0 4354 2565 Fax. +358 0 461 617