🚀 go-pugleaf

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