"First sub-goal: Must work in Win98. Once achieved then then next staging post: Must work in Win2K." and so on.

The idea is that you can assure yourself that the module does not need anything external from some other file included by the test program.

The idea if self compilation does not stop one also having whatever hierarchy you want. Each file still has its own includes that it must have. If it doesn't compile then you have forgotten to include something.

MODULE ModuleName, list of exported names
  ; module body
ENDM    

However, I would say that compilation without execution doesn't make much sense in assembly because it provides virtually no assurance the code would work (wich is not the case with hi-level languages).

Do you think it's hard to create macros to hide module internals?
I mean something like this

Code:

MODULE ModuleName, list of exported names
  ; module body
ENDM    

Outside the module: names that are in the list are accessible as ModuleName.name, others are invisible.

booter wrote:

However, I would say that compilation without execution doesn't make much sense in assembly because it provides virtually no assurance the code would work (wich is not the case with hi-level languages).

It is just a test to make sure everything you need has been included, and thus the module can be included by other code without having to also include the modules sub-dependencies. The test program is there to do the assurance.

A needs B, and B needs C.

So A includes B and should not have to know that B needs C. Because if B then changes and now needs D and not C then you don't want to have to go back and edit A to remove C and include D. Changing module B should not affect other code that needs to include B. What if you forgot that module X also includes B and fail to edit module X also to change from C to D? What if you come back 6 months later and wonder why A includes C (or D) when A doesn't use C? It gets messy when you require other code to include stuff that your module needs.

For a multi-developer project (which is what these principles were meant to cover) the communication overhead needs to be kept small else errors will easily creep in. booter, in your scenario, If module B (developed by person B) is changed to be more efficient (or something) then person B then has to communicate that to person A to change things in another module not controlled be person B. And what if person B is not aware that module X also needs changing? Things start to get confusing.

When I include 'gdi32.dll" in a windows program I don't have to care that gdi32 also needs user32 and kernel32 etc. I just only include gdi32 and never need to concern myself with how gdi32 does its job. You have to trust the people you assign jobs to else why assign the job at all.