MultipleExe's in a 'stand alone' 
Its sort of pattern. 

1. I'm a lone (VB6)programmer, so not a professional like the people who work in a team for a big firm, still it makes sense. 

2. Problem. 
I think up something, start with a SpikeSolution, next the program grows and grows, '''eventually I get lost.''' 

This problem is caused mainly by the size of the program combined with lack of good architecture). 

3. Solution 
Now I found a good solution: '''multiple exe's.''' 
E.g. If the program generates a lot of data and you want to show this in some graphics, or you want to analyse a datafile and show it in a grid, you can write a graphicsViewer.exe and a gridAnalyser.exe that are called by the mainApp. 

This standalones in themselves are much smaller, so its easy to understand and maintain the code. 

The only problem now is to make the different exe's communicate in a good way. 
Probably a lot of smart people have handled this communication among different programs in a real smart way, and you may even find a lot on this subject elsewhere in this wiki. (So If you have any good or bad experiences with multiple exes please add yout tips and comments) 

Anyhow: I handle all communications among different exe's this way: 

Call an addOn with a command$ to pass information. (see ShellCall) 
I also add a timer to every addOn, to look into a multiple file every second 

This mutilple file has a few key.value pairs , I use just two Subs. (You'll have to write the code yourself): 
 Call writeSettingsTo (key, value, mutualFile) 
 Call readSettingsFrom (key, mutualFile) 

E.g I can close an addOn by the mainApp 
  in mainApp: 
  writeSettings ("end", "true", mutualFile) 
  in addOn: 
  If readSettings ("end", mutualFile) = "true" then 
  call writeSettings ("end", "false", mutualFile) 
  end 
  end if 

Other informations can also be passed by this mutiple file, but best you pass as little as possible, as all communications make it harder to understand thew programs. 
---- 
'''Advantages''' 

1.Missing addOn. If an addOn is missing, then the mainApp will still run. 

2. Bugs. If you do not add code to the main program but to an addOn.exe then a bug in the addOn will not crash the main program. 

3. Complexity. Whenever you try to solve a problem with just try and error writing code, you will not get mixed up, as the code is a separate exe, still you can use it right away as an addOn to the mainApp. Later, if you find a very simple concise solution you can also cut and paste it into the mainApp. 

4. MultiThreading. They say multiThreading isn't possible in VB6 (well, what's so good about multiThreading on a simple PC is not clear to me anyhow), but every addOn to the mainApp will have a thread of its own. 

5. I'm not good is abstract thinking, I want to see and know whats going on before I understand, so I think MultipleExe's a very clear and easy solution. Other people may be different so they may look upon me as a blacksmith forging iron in the fire. So it may not be a general solution, but it works out fine with me. 
----- 
Comments

This sounds to me like the philosophy behind the various Unices...