Joe,
 
We had the app partitioned years ago into multiple .EXE, but we moved towards a single .EXE since we bring many enhancements online every month and would sometimes have incompatible .EXE  in use.  A single .EXE replaced all changes in a single operation.  It is our call depth and the overall size of the active variables that contributes to the stability issues.  Below is our app diagnostic screen.  Note that some diagnostic api's do not know about modern CPU/OS/MEM and hence report obsolete info.  This screen was actually captured on a Win2K3 server with 3Gb physical ram in an RDP session.  We froze our app on 7/13/05 during the migration to Xbase++.
 
┌─┤Info for N:\SYS2005\BIN\SYS2005I.EXE 07/13/05 18:56:16├───────┐
│ Wednesday, September 14, 2005                                 11:16:49p │
├───────────────────────────────────────┤
│       BLINKER VERSION v7.00                 MAX FILE HANDLES 250        │
│ STATIC SPACE LOCATION BLINKER ENHANCED   FILE HANDLES IN USE 7          │
│STATIC SPACE AVAILABLE 55KB                  OPERATING SYSTEM DOS 5.00   │
│ LOCAL SPACE AVAILABLE 15KB                         TOTAL MEM 14735KB    │
│     TOTAL LOCAL SPACE 20KB                    CONTIGUOUS MEM 64KB       │
│   FREE DYNAMIC MEMORY 28672KB                   RUN COMMANDS 407KB      │
│        PROCESSOR MODE PROTECTED                FLOPPY DISK A 1.44 MB    │
│           MEMORY HOST DPMI                     FLOPPY DISK B NONE       │
│  VIR MEMORY AVAILABLE 28672KB                   MONITOR TYPE VGA        │
│     CLIPPER TOOLS LIB v5.20 - 3.0b (OK)       PARALLEL PORTS 3          │
│            LOGIN NAME RODD                               CPU 80486      │
│             FULL NAME Rodd Graham                BASE MEMORY 640KB      │
│     AVAIL. DISK SPACE N/A                    EXTENDED MEMORY 1024KB     │
│      ENVIRONMENT SIZE N/A                  FREE STACK MEMORY 6316B      │
│      ENVIRONMENT USED 2342B                 MATH COPROCESSOR INSTALLED  │
│       CLIPPER VERSION Clipper (R) 5.2e (x216)  (1995.02.07)             │
│     Advantage RDD for CA-Clipper 5.2, CDX/IDX, 7.0, 09/12/03, 5:20a     │
└───────────────────────────────────────┘ 
 
The local space available (from the Blinker diagnostic api) and free stack memory are the most critical because of the call depth and number of variables.  These are a balancing act since increasing one decreases the other (both in a single 64K segment along with all C near data segments)
 
> What is 332 SVOS exhaustion error?
 
Non-recoverable runtime error of the Clipper system.  Essentially, variable memory is full and cannot make a requested allocation.  It is documented in the Clipper guides.  Since it is non-recoverable, no errorsys(), just crash/exit.
 
> What is DPMI memory anomaly?
When Blinker protected mode programs run under WinNt/2K/XP/2K3, they use Dos Protected Mode Interface (DPMI) of Windows to run outside of the 640K MsDos memory space.  Our app needs at least 8 MB of DPMI memory to work.  We occassionally see DPMI memory available in all NTVDM sessions drop to less than 3MB for periods of a few minutes even though the system has 1GB physical ram.  When this occurs, our app cannot run.
 
Rodd
"Joe Carrick" <joe.carrick@dslextreme.com> wrote in messagenews:rbRmcjWuFHA.5608@S15147418...
> Hi Rodd,
>
> Our Clipper App is 5.2e, Blinker 7 linked and App is (6) 600-900 KB
> EXE's which are overlayed from a single 500 KB EXE.  We don't use ClassY
> and we don't use ADS.  We have not experienced any of the problems you
> mention.
>
> What is 332 SVOS exhaustion error?
> What is DPMI memory anomaly?
>
> Frankly, these sound like problems resulting from something other than
> Clipper per se.
>
> -Joe
>
> Rodd Graham wrote:
>> Joe,
>>
>> We have experienced three critical problems on WinXP sp2 with Clipper of
>> which we have only solved one.  Clipper app is 5.2e, Classy 2.4b, Blinker 7
>> linked, ADS 7.1 and .EXE is approx 2M.  App is deep with 50 routine call
>> stack and 8-12MB live variables not unusual.
>>
>> As app has expanded to more capability, 332 SVOS exhaustion errors have
>> become a multiple time a day problem for all users.  We have not solved this
>> problem.
>>
>> Clipper app is hard to properly allocate CPU when idle and processing.
>> WinXP introduced aggressive idle detection that backs off Clipper when it is
>> actually processing.  Conversely, disabling idle detection destroys system
>> performance by consuming CPU 100%.  This problem is solved via TameDos.
>>
>> Windows XP introduced a DPMI memory anomaly in our configuration that causes
>> periods of DPMI memory depletion during which the Clipper app becomes
>> vulnerable to memory exhaustion.  We have confirmed the DPMI problem with a
>> DPMI diagnostic utility.  Unfortunately, DPMI docs and solutions are very
>> sparse.  We have not solved this problem.
>>
>> It is at this point that the decision was made to migrate to Xbase++ to open
>> up more runtime memory space.
>>
>> Rodd
>>
>> "Joe Carrick" <joe.carrick@dslextreme.com> wrote in message
>>news:E22RmhVuFHA.1256@S15147418...
>>
>>>Hi James,
>>>
>>>We have a Clipper App that is still running just fine on WinXP_Pro with
>>>SP2.  The only problem is with newer Monitors where it's necessary to
>>>start it in a window and then change the properties to full screen so the
>>>mouse works properly.
>>>
>>>-Joe
>>>
>>>James Loughner wrote:
>>>
>>>>Joe, a reason might be that the new 64 bit OS's are not supporting 16 bit
>>>>programs any more!!!!
>>>>
>>>>Jim
>>>>
>>>>Joe Carrick wrote:
>>>>
>>>>
>>>>>Hi Rodd,
>>>>>
>>>>>What is your goal?  Do you want a GUI (WindowsTM) App or an App that
>>>>>looks like DOS?  If the latter, then the next question is why not stick
>>>>>with Clipper?  You will find that Clipper Apps are going to be faster,
>>>>>but you may have some problems with WindowsXP and newer Monitors.
>>>>>
>>>>>IMO, the GUI Object Oriented Environment ultimately provides a much more
>>>>>flexible App, but it also presents some new programming challenges.
>>>>>
>>>>>If you eventually want a GUI App then just bite the bullet and go
>>>>>directly to GUI.
>>>>>
>>>>>-Joe
>>>>>
>>>>>Rodd Graham wrote:
>>>>>
>>>>>
>>>>>>Raymond,
>>>>>>
>>>>>>But if I am migrating existing Clipper, wouldn't it be 'why do the work
>>>>>>once'.  Doesn't the VIO mode provide a functionally equivalent
>>>>>>operation to the Clipper app?
>>>>>>
>>>>>>However, with multiple suggestions to TopDown and Express++, I will
>>>>>>need to investigate prior to going GUI.
>>>>>>
>>>>>>Rodd
>>>>>>
>>>>>>"Raymond Fischbach" <r_fischbach@nospam.tvcablenet.be> wrote in message
>>>>>>news:rsxy30ncbml0$.tj7hsmv4bonr.dlg@40tude.net...
>>>>>>
>>>>>>
>>>>>>>On Tue, 13 Sep 2005 16:57:01 -0500, Rodd Graham wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Did anyone (or everyone) who migrated Clipper apps to Xbase++ go
>>>>>>>>straight to
>>>>>>>>GUI with XbpCrt or make a detour to VIO?
>>>>>>>>
>>>>>>>>I assumed that VIO was the least disruptive to our production
>>>>>>>>enviroment,
>>>>>>>>but I don't get the impression that anyone else is using VIO apps.
>>>>>>>>
>>>>>>>>Rodd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>I would suggest you to go directly to GUI.
>>>>>>>Why doing the work twice ?
>>>>>>>
>>>>>>>And if you don't want to reinvent the wheel, try Clayton Jone's
>>>>>>>TopDown
>>>>>>>Library. It will save you hundreds of hours of work.
>>>>>>>
>>>>>>>
>>>>>>>--
>>>>>>>Raymond Fischbach
>>>>>>>Belgium
>>>>>>>http://www.mouches.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>