Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: F45RUN32 on NT 4.0.Lot of memory.

Re: F45RUN32 on NT 4.0.Lot of memory.

From: Billy Verreynne <vslabs_at_onwe.co.za>
Date: Tue, 19 May 1998 09:15:08 +0200
Message-ID: <6jrbdc$hld$1@hermes.is.co.za>


Albert Aymerich wrote in message <01bd7e9a$de889bc0$edc9c8c1_at_sgo01>...
>Here is my trouble:
>
>F45RUN32 on W95 is loaded into memory only once (it takes about 8-9 MB).
>
>And now, we are going to NT 4.0.
>On Windows NT 4.0, every time that F45RUN32 is called, it is loaded into
>memory. And this is a problem because our application could call more than
>only one forms (maybe 3,4,5,... ). That's represents a lot of memory on the
>client machine.

I don't agree with this statement. The Forms RTS (run time system) is a 32 bit application. 32bit applications are run in seperated memory spaces (or 32bit Virtual Machines) on -both- NT and Win95. The memory overheads for a 32bit VM on NT is slightly larger than on Win'95 and for good reason - it is require to "protect" that VM.

If a single Forms application opens multiple forms, these forms have the -same- application handle and therefore run in the -same- 32bit VM. NT does not (nor Win'95 for that matter) open a seperate VM for each window handle.

A major difference between NT and Win'95 is the way 16bit apps are handled. On Win'95 all Windows 16bit apps run in a -single- 16bit VM (the same as Windows 3.1). However, 16bit DOS applications are run in -seperate- VMs. With NT you have an option. You can select to run a 16bit Windows app in a seperate VM (require additional resources and overheads but protects that app against other 16bit Windows apps), or in the same VM as the other 16bit Windows apps (less overheads, but greater change that one bad app will crash the VM taking all the other apps in that VM with it). And as with Win'95, DOS apps are run in seperate 16bit VMs on NT too.

Run time systems. Well, most of them consist of DLLs. 32bit DLLs behave the same way on both Win'95 and NT (won't get into 16bit - n.a. and a bit more complex). Any piece of software has 2 segments - a code segment (containing the machine code instructions) and a data segment (for variables). A DLL's code segment is only loaded once by Windows. When an app uses that DLL, that DLL's data segment resides in the data segment space of the calling application.

Let's say Forms App 123 is started. It "activates" the Forms RTS. Windows ('95/NT) loads these DLLs into memory and set the usage counter to 1. Forms App XYZ is now loaded. It also wants to use the Forms RTS. Windows sees that the DLLs are already loaded, and increment the usage count to 2. When these apps terminate, the usage count is decremented. When the usage counts reaches zero, Windows automatically unloads the DLL from memory. The code segment is therefore only load once in both '95 and NT. So the basic memory footprint of a 32bit DLL is the -same- on both Win'95 and NT.

I find it strange that the perception is that on NT, Forms has a much larger memory footprint. OK, this may seem the case if you run Forms on a 32MB RAM Win'95 and a 32MB RAM NT machine. NT itself requires more memory than Win'95. Therefore there will be less of the 32MB RAM left for use by applications after NT is loaded. However, NT's memory protection and model are far superior than the bastardised 16bit/32bit implementation of Win'95.

IMHO Forms sucks. Use a proper client-server development environment like Delphi that addresses the complete enterprise architecture, from client, middleware to server and that gives you C++ performance, a better design environment than VB, small memory overheads, flexibility and power.

regards,
Billy Received on Tue May 19 1998 - 02:15:08 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US