How to organise a large project

[michael_green]

I have to convert a large system (a GIS) written in Fortran 77 on an OpenVMS platform to CVF. The old system consists of a menu program which spawns subprocesses to run users' choices from the menu. The whole system is basically a large box of tools consisting of about 60 programs ranging from one of 29000 lines down to many of just a few hundred.

Can anyone advise me on how to organise this sort of thing in CVF? One huge monolithic program would end up having more than 400 subroutines I guess, which sounds like a bad idea. Should I write what were the old subprograms as separate programs again and run them with WinExec? Any comments and suggestions would be most welcome.

With many thanks

Mike

[Jugoslav_Dujic]

GIS = Geographic Information System? (Just out of curiosity)

I'll start with how I would organize it within CVF IDE: first, within the root directory (let's call it GIS), create sub- (sub-sub-) directories for each tool. Copy the code of each tool to its directory. Put shared files into GIS/Shared directory.

Then, make a project (.dsp) file for every tool in its directory. Insert all projects into GIS workspace (Project/Insert Project into Workspace). You can switch active projects using Project/Set Active Project or by switching on "Build" toolbar.

Create a "GIS/Bin" directory; for all project files, set "Output file name" to "..BinTool.exe", so that all executables end up in GIS/Bin. You can build entire working set using Build/Batch build command. A utility such as File Substring Replacement Utility, and/or few VS macros can help automate the task.

Now, you have all source files at hand, reasonably well organized in folders and corresponding subprojects (managing 60 projects is still a pain, I know).

As for what the tools should become, I'd use roughly the following approach (of course, I don't know anything about your system):
- For most of the tools, make them DLL's. I mean ones which are used frequently, don't consume too much memory and are reasonably well tied to the "stub" body. After you convert them to DLLs, insert them as dependency of the main project (Project/Dependencies).
[Hint: you can change the existing project without recreating it by just changing project settings (/subsystem switch is the most important). The easiest way to find out is to create a small .exe and a .dll project and compare the differences in .dsp files in textual mode to see what exactly should be changed.

- Convert small tools to normal subroutines within the "main" program, so that you reduce the number of 60 to something more reasonable.]

- Tools which are not tied well to the rest of the system and/or consume too much memory, and/or should run asynchronously should retain as .exes.

Hope this helps
Jugoslav

[michael_green]

Thanks for the help, Jugoslav, yes GIS = Geographical Information System.

I have tried hard to follow your advice and have learnt much, but since this is the first time I have done anything like this I still have some conceptual problems. In the old system, when a user has chosen an item from the main menu, a subprocess is spawned which runs a program consisting of a number of dialogs. The user responds and the program writes a command file which is submitted to a batch queue where another program does the real work of number crunching to get the result. For every dialog program there is a corresponding number cruncher.

For the most part, the number crunchers will port as is to CVF, but I'm not sure how to connect the whole thing together. Based on your previous advice, I presume I should write the main menu program as a Single Document Interface, specifying that DLLs will be used (done that). Then this is where I get confused. With the dialog programs in mind, when I specify New/Project do I select Fortran Dynamic Link Library or do I select Fortran Windows Application and go on to specify a dialog based application? Then, after that step, whichever way it goes, how do I link in the number crunchers? As DLLs too I suppose - linked to the dialog programs?

So I guess I've got two types of problem here. First, the concepts, and second the mechanics of actually doing it. I've tried the CVF samples but find them either too simple or too complex for me to generalise to my case.

With many thanks once again,

Mike

[Jugoslav_Dujic]

I'll try to summarize your options, with comments. For sake of brevity, I'll call the main program "GIS", one number-crunching unit "Tool", and its corresponding dialog "ToolDlg". I really don't know enough about your system to tell you which path I would take.

1) Keep all ToolDlgs within GIS project, and Tools within separate Dlls. This has the advantage that all GUI code is within one project and all Tools modular & portable. The disadvantage is that all Tools will be loaded into memory at once (which may or may not be an issue for you).

2) (Similar to 1) Keep all ToolDlgs within GIS project, and Tools as separate Exes. The same advantages as (1). Inter-process communication is harder (if it will be through files, it's not a big deal).

3) Keep all ToolDlgs along with Tools in separate exes. This has the advantage of keeping memory usage low and separation by functionality. The disadvantage is that you bind the ToolDlg and Tools code.

4) Keep ToolDlg's within separate .exes, Tools within .dll's. Advantage is that functionality is quite separated, but total number of projects is (too?) big.

5) Variations between 1-4 are possible as well etc.

Have an eye on the fact that you (maybe?) need queueing. Both exe's and dll's can be queued or ran synchronously, depending on what you need (CreateProcess/WaitForSingleObject for .exe's, CreateThread/WaitForSingleObject for .dll's). With threads, you get bigger efficiency (CreateProcess is slow) and better communication within units (e.g. share the same variables) but more headache with inter-thread synchronization (two threads may not write into same variable simultaneously, one may have to wait for another to finish, etc.)

Dialog-based programs should be of type "Fortran Windows Application". There's an option for dialog-based application in the AppWizard, but the generated code is overcomplicated. I suggest you create an empty application and just write (or copy from an existing one):

integer function WinMain(...)
!dec$attributes stdcall,...
use DFLOGM
type (Dialog):: Dlg
DlgInit(IDD_DIALOG,Dlg)
DlgSet(...)
DlgModal(Dlg)
WinMain = 0
end function

It's a perfectly valid dialog-based application -- e.g. just dialog-handling code within body of WinMain.

Dialogs may reside in Dll's (see DlgInitWithResourceHandle and LoadLibrary) but I don't like that idea much.

Jugoslav

[michael_green]

Thankyou so much, Jugoslav. That's more than enough to get me going - I think I'll go with your option 2.

Many thanks again,

Mike