jerry@olivey.olivetti.com (Jerry Aguirre) (12/08/90)
We have a windows application (XVision) that winds up opening up a lot of nested windows. It can not quite open enough for the application as it runs out of "system resources". This seems to be related to the "Free System Resources" listed on the HELP/ABOUT program manager screen. Stripping out other icons increases this and helps the problem but at the expense of making windows otherwise useless. Is there some option to allocate more of these "resources"? Jerry Aguirre
tonyd@hplsla.HP.COM (Tony DeMartino) (12/10/90)
If you haven't already done so, you can increase the size of your RAM or you can increase the size of your swap file by making it permanent. Your manual describes the installation of a permanent swap file in the Tuning Windows section.
jls@hsv3.UUCP (James Seidman) (12/11/90)
In article <3130042@hplsla.HP.COM> tonyd@hplsla.HP.COM (Tony DeMartino) writes: >If you haven't already done so, you can increase the size of your RAM or >you can increase the size of your swap file by making it permanent. Your >manual describes the installation of a permanent swap file in the Tuning >Windows section. He could do this, but this won't solve his problem. "System resources" and free memory are two very different things. Windows has a several things which you can only have a limited number of. The most restrictive is probably that you can only have 8192 windows. (Before you say, "Boy, that's a lot!" think for a minute. Every dialog box control, icon, icon title, scroll bar, etc. is a window. You can use up a lot of them in one application.) There is no way to increase this number, except maybe waiting for Windows 3.1. (I don't know if they plan to increase this or not.) -- Jim Seidman (Drax), the accidental engineer. "It doesn't have to work... they'll be paralyzed just from laughing at me." - Dr. Who, _Shada_ UUCP: ames!vsi1!hsv3!jls INTERNET: hsv3.UUCP!jls@apple.com
gg2@cunixf.cc.columbia.edu (Guy Gallo) (12/11/90)
In article <3130042@hplsla.HP.COM> tonyd@hplsla.HP.COM (Tony DeMartino) writes: > > >If you haven't already done so, you can increase the size of your RAM or >you can increase the size of your swap file by making it permanent. Your >manual describes the installation of a permanent swap file in the Tuning >Windows section. > Actually, increasing the amount of absolute memory has little if anything to do with freeing up "resources". From a message posted this week in MSAPP on compuserve by an MS employee it was clear that resources are allocated each time you open a dialog box or a list box (or a folder full of icons), and that when a program exits, those resources are not released. There is a 64K chunk allocated to these resources -- and with a 512 byte chunk here and a 512 byte chunk there -- unreleased -- that 64k becomes fragmented. The only solution is to close windows and start again. Other tips include: Closing un-needed windows. Iconize apps. And set Program Manager so that it starts up with the fewest possible icons showing -- when it starts space for all visible icons are allocated at the top. Hope this helps.
rb9a@watt.acc.Virginia.EDU (Raul Baragiola) (12/11/90)
In article <6176@hsv3.UUCP> jls@hsv3.UUCP (James Seidman) writes: > >Windows has a several things which you can only have a limited number >of. The most restrictive is probably that you can only have 8192 windows. >(Before you say, "Boy, that's a lot!" think for a minute. Every dialog >box control, icon, icon title, scroll bar, etc. is a window. You can use >up a lot of them in one application.) There is no way to increase this >number, except maybe waiting for Windows 3.1. (I don't know if they plan >to increase this or not.) > I thought a minute, and boy, even that is a lot! Imagine 40 such windows per application. You would then be limited to 200 applications, not really a problem for mortals. I hope any 'improvement' of this sort to version 3.1 does not make Windows use more memory and CPU. Right now, the main weakness I see is that it makes your 386 look like a pretty 8MHz AT. Which brings me to the point raised by another netter as a question. If I want to run something fast (like a simulation) I have to go out of Windows, loosing its multitasking ability. This doesn't have to be like that, it should be possible to use 80% of the CPU for the simulation in the background and share 20% for word processing, printer spooling and communications. Cheers, and happy holidays Raul A. Baragiola \Internet: raul@virginia.edu Dept. Nuclear Engnr. and Engnr. Physics \Phone: (804)-982-2907 University of Virginia, Charlottesville, VA 22901 \ Fax: (804)-924-6270
spolsky-joel@cs.yale.edu (Joel Spolsky) (12/12/90)
In article <1990Dec11.152056.18243@murdoch.acc.Virginia.EDU> rb9a@watt.acc.Virginia.EDU (Raul Baragiola) writes: > If I want >to run something fast (like a simulation) I have to go out of Windows, >loosing its multitasking ability. This doesn't have to be like that, it >should be possible to use 80% of the CPU for the simulation in the >background and share 20% for word processing, printer spooling and >communications. Why can't you do that? Joel Spolsky
geoff@nluug.nl (G. Coupe EPD/74 O75/1435) (12/12/90)
In article <1990Dec11.152056.18243@murdoch.acc.Virginia.EDU> rb9a@watt.acc.Virginia.EDU (Raul Baragiola) writes: >In article <6176@hsv3.UUCP> jls@hsv3.UUCP (James Seidman) writes: >> >>Windows has a several things which you can only have a limited number >>of. The most restrictive is probably that you can only have 8192 windows. >>(Before you say, "Boy, that's a lot!" think for a minute. Every dialog >>box control, icon, icon title, scroll bar, etc. is a window. You can use >>up a lot of them in one application.) There is no way to increase this >>number, except maybe waiting for Windows 3.1. (I don't know if they plan >>to increase this or not.) >> >I thought a minute, and boy, even that is a lot! Imagine 40 such windows >per application. You would then be limited to 200 applications, not really >a problem for mortals. > >Raul A. Baragiola \Internet: raul@virginia.edu >Dept. Nuclear Engnr. and Engnr. Physics \Phone: (804)-982-2907 >University of Virginia, Charlottesville, VA 22901 \ Fax: (804)-924-6270 Raul, I'm afraid it is a problem for us mere mortals. This thread got started with a problem associated with XVision, an X server product for MS Windows. It's a good product, but recently I tried to use it to access TeleUse - an interactive Motif development tool that we have in on evaluation. My Compaq has 8Mb real memory and a 3Mb permanent swap file. Before starting Teleuse, the W3 program manager says that 67% system resources are free. Once Teleuse starts, I'm down to 1% free, and the whole system grinds to a halt. The problem appears to be that TeleUse uses icons like they're going out of fashion, and has very complex screens, so XVision has to ask a lot from MS Windows in the way of resources. Obviously, Windows 3.0 doesn't seem up to the job, and I'm worried if these limits are not going to be addressed in 3.1. Today, TeleUse might be thought of as an unusually hungry program, tomorrow it will probably thought of as typical and Windows programs themselves will be wanting the same scale of resources... Geoff Coupe geoff%epd74hp@nluug.nl
bcw@rti.rti.org (Bruce Wright) (12/15/90)
In article <1990Dec11.152056.18243@murdoch.acc.Virginia.EDU>, rb9a@watt.acc.Virginia.EDU (Raul Baragiola) writes: > In article <6176@hsv3.UUCP> jls@hsv3.UUCP (James Seidman) writes: > > > >Windows has a several things which you can only have a limited number > >of. The most restrictive is probably that you can only have 8192 windows. > >(Before you say, "Boy, that's a lot!" think for a minute. Every dialog > >box control, icon, icon title, scroll bar, etc. is a window. You can use > >up a lot of them in one application.) There is no way to increase this > >number, except maybe waiting for Windows 3.1. (I don't know if they plan > >to increase this or not.) > > > I thought a minute, and boy, even that is a lot! Imagine 40 such windows > per application. You would then be limited to 200 applications, not really > a problem for mortals. I hope any 'improvement' of this sort to version > 3.1 does not make Windows use more memory and CPU. Right now, the main > weakness I see is that it makes your 386 look like a pretty 8MHz AT. I think 40 windows is a gross underestimate for anything other than the simplest Windows programs. There really are a LOT more windows created than you think. Every button that's created (including the "system menu" buttons and "minimize" and "maximize" on the typical main application window), every menu that drops down, every caption bar, etc, etc, is a window. So is the frame around the typical application window. And the MDI interface such as that used by the Program Manager uses up windows like they're going out of style. It really takes no time at all to use up 40 windows - probably almost any "mini-app" uses up that many. For a real application, try 400 or more. That still allows 20 apps to run at once, but then you can encounter greedy apps that create more than the "normal" app - like, say, 4000, and you can be in trouble. > Which > brings me to the point raised by another netter as a question. If I want > to run something fast (like a simulation) I have to go out of Windows, > loosing its multitasking ability. This doesn't have to be like that, it > should be possible to use 80% of the CPU for the simulation in the > background and share 20% for word processing, printer spooling and > communications. I think we need more information on the problem you're having. Is the simulation program a normal DOS program, or a Windows program? Are you running in 386 mode or Standard Mode? (If it's a normal DOS program and you're running in Standard mode you won't be able to run simulations in the background in a reasonable way). Does the program use graphics? If so, and if it's a normal DOS program, Windows doesn't provide very efficient emulation of the graphics card for such programs and you may be better off to run the program outside Windows or convert it to run under Windows. It really isn't a big problem to convert number-crunching programs to Windows, at least if they are writtin in C. You would have to insert a call to a little routine to do a PeekMessage loop at appropriate places in the program, but this is pretty easy (I can supply details if needed, as can others in this newsgroup). There _may_ be problems with the output (standard C output isn't supported), but for most cases this can be dealt with without too much of a problem. The worst problems for converting a program to Windows are usually graphics (the Windows graphics model may not match the model that the programs use) and user interaction (the message structure of Windows is quite different for user interface programming than a typical interactive environment). If these are not major parts of the program it's pretty easy to provide the necessary boilerplate to make the application Windows-compliant. Converting a highly interactive program, on the other hand, can be a major pain. Unfortunately most programs (unlike simulations) tend to be more interactive than compute bound. Bruce C. Wright
rb9a@kelvin.seas.Virginia.EDU (Raul Baragiola) (12/15/90)
In article <1990Dec14.181308.27047@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: >In article <1990Dec11.152056.18243@murdoch.acc.Virginia.EDU>, rb9a@watt.acc.Virginia.EDU (Raul Baragiola) writes: >> In article <6176@hsv3.UUCP> jls@hsv3.UUCP (James Seidman) writes: >> > >> Which >> brings me to the point raised by another netter as a question. If I want >> to run something fast (like a simulation) I have to go out of Windows, >> loosing its multitasking ability. This doesn't have to be like that, it >> should be possible to use 80% of the CPU for the simulation in the >> background and share 20% for word processing, printer spooling and >> communications. > >I think we need more information on the problem you're having. Is the >simulation program a normal DOS program, or a Windows program? Are >you running in 386 mode or Standard Mode? (If it's a normal DOS >program and you're running in Standard mode you won't be able to run >simulations in the background in a reasonable way). Does the program >use graphics? If so, and if it's a normal DOS program, Windows doesn't >provide very efficient emulation of the graphics card for such programs >and you may be better off to run the program outside Windows or convert >it to run under Windows. > I'm using 386 mode. But what I describe is not _my_ problem. Several netters have posted many times in this newsgroup about it. I also remember some benchmark and someone reporting of all the permutations on switch settings. My problem is not limited to a particular program, but in the specific case of the simulation, it is a normal DOS application which uses graphics (but not when it is running in background). >It really isn't a big problem to convert number-crunching programs >to Windows, at least if they are writtin in C. Only 2% of my programs are written in C. But I think the question is: what is the overhead (in CPU time) imposed by the Windows environment? How can it be lowered? In many scientific applications we are not concerned with graphics or I/O, just with pure MFLOPS (sorry for that ill-defined term, but you know what I mean). And I want to use the computer for other things (like word processing, communications) while more than 80% of the speed of the CPU is being used in the background task. Is this asking too much? -- Raul A. Baragiola \Internet: raul@virginia.edu Dept. Nuclear Engnr. and Engnr. Physics \Phone: (804)-982-2907 University of Virginia, Charlottesville, VA 22901 \ Fax: (804)-924-6270
chrisg@microsoft.UUCP (Chris GUZAK) (12/24/90)
In article <1990Dec11.090947.5379@cunixf.cc.columbia.edu> gg2@cunixf.cc.columbia.edu (Guy Gallo) writes: >Actually, increasing the amount of absolute memory has little >if anything to do with freeing up "resources". From a message >posted this week in MSAPP on compuserve by an MS employee it was >clear that resources are allocated each time you open a dialog box >or a list box (or a folder full of icons), and that when a program >exits, those resources are not released. There is a 64K chunk >allocated to these resources -- and with a 512 byte chunk here and >a 512 byte chunk there -- unreleased -- that 64k becomes fragmented. This is not true. If this is happening there are bugs in the APPS that you are running. If you find such a bug report it to your app vendor. Windows has been tested very carefully to make sure there are no internal leaks like this. Chris Guzak