Xref: utzoo comp.sys.att:6277 unix-pc.general:2808 Path: utzoo!utgpu!watmath!uunet!cs.utexas.edu!execu!sequoia!attdso!shuxd!att!cbnewsh!ho5cad!wjc From: wjc@ho5cad.ATT.COM (Bill Carpenter) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: more windows on unixpc (screen memory) Message-ID: Date: 29 Apr 89 18:01:23 GMT References: <677@icus.islp.ny.us> <482@limbic.UUCP> <757@ivucsb.UUCP> <484@limbic.UUCP> Sender: nntp@cbnewsh.ATT.COM Distribution: na Organization: AT&T Bell Laboratories Lines: 26 In-reply-to: gil@limbic.UUCP's message of 28 Apr 89 23:03:22 GMT In article <484@limbic.UUCP> gil@limbic.UUCP (Gil Kloepfer Jr.) writes: > Yeah, it *will* eat more kernel memory...which I would like to have available > for device drivers for other things .. like maybe the proposed SCSI board > being worked on, voice power board, my own device drivers, etc. Although > it's THERE, it's not there to waste. > > If the window driver is to use memory like it does, the parameter should > be tunable, or it should allocate/free virtual memory at window create/delete No doubt about it. Bitmaps for windows could get up to about 30k each. That's not much in a regular old program, but it's enormous in kernel country. Sure makes you wish there were a user space window manager available, doesn't it? It would probably not be possible to completely emulate the existing window system without dipping into a little kernel sorcery, but you could probably come pretty close. If you didn't care much about compatibility with the native stuff, you could probably just port some existing free window system. Like, f'r'instance, "X" (probably too hard to be practical) or "mgr" (I have the author's list of things needed to change for SysV, but I don't have the time to try it soon). -- -- Bill Carpenter att!ho5cad!wjc or attmail!bill