I've got a legacy ASP web application that uses a VB6 DLL. The app is quite memory hungry. I need to run multiple instances of the app on one machine. Now since VB6 DLLs are 32bit only, running in a 64bit process is out - but what if I ran multiple 32bit IIS app pools? Would the memory limit of 1.2 GB per kick in per app pool, or would there by a memory limit for all app pool processes aggregated? Anyone who has experience with that?
but what if I ran multiple 32bit IIS app pools? Would the memory limit of 1.2 GB per kick in per app pool, or would there by a memory limit for all app pool processes aggregated?
The per process limit applies per process, and each app pool is in its own process. So you can make use of an arbitrary large amount of memory by running lots of app pools.
Also, it is not 1.2GB, but 4GB.
By default a 32bit process gets 2GB of "user space", unless the exe is built with the "Large Address Aware" flag, in which case it gets 3GB on a 32bit OS with the appropriate boot time flag (which limits kernel space—with its own consequences) but on a 64bit OS it is 4GB user space (no boot flag needed, and no kernel memory consequences).
w3wp.exe (the executable that hosts app pools) is built with the Large Address Aware flag, as can be seen from running
dumpbin /headers w3wp.exe in the
Just to add a nuance in your original post, you CAN effectively use this 32-bit DLL from a native IIS 64-bit Application Pool.
Basically, you have to encapsulate this DLL using a COM+ Component Service. This will take you 5 minutes, and you can use your regular Classic ASP source code, without any change (Server.CreateObject).
I am using this procedure for some of my custom DLLS, and for other that are not available anymore in any other version than a 32-bit DLL.
The procedure is explained here : http://www.chestysoft.com/component-services.asp