flat assembler
Message board for the users of flat assembler.

Index > Projects and Ideas > Principles for creating multi-developer programs with fasm

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
booter



Joined: 08 Dec 2006
Posts: 67
booter
revolution wrote:

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

Implementation of "Must work in Win98" and "Must work in Win98 and later in W2K" would be different and the 2nd one would require less changes for W2K. I mean one should keep in mind future needs and provide capabilities to extend current functionality in the future.

revolution wrote:

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.

I see, you're implementing "star"-like modularity, where each module can be used independently. I prefer layered program structure, where higher level modules are based on lower level and obviously use them to compile and run. Of course, lower modules can not use functionality from the higher level. For example, "base" level module that provides debugging output can not use functions from "strings", but "strings" should be able to call debugging printout functions. Hierarchy of the modules corresponds to the order of includes. Wrong order causes compilation error.
Post 28 Dec 2009, 11:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
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.
Post 28 Dec 2009, 14:42
View user's profile Send private message Visit poster's website Reply with quote
booter



Joined: 08 Dec 2006
Posts: 67
booter
revolution wrote:
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.
Sorry, it wasn't clear to me that your approach is very different from mine. I allow includes only in main program and don't specify dependences in modules. Example of my approach:
Suppose you have modules A,B,C,D.
B, C, D depend on A.
C and D depend on B, but not on each other.
Test programs would be
TestA includes A
TestB includes A and B
TestC includes A,B,C
TestD includes A,B,D
Application that needs functionality from all modules includes A,B,C,D or A,B,D,C
One can also create TestAll testing program that includes all existing modules in proper order to detect incompatibilities.
"Test"-programs are very important because they demonstrate functionality of the modulees and provide a reference for usage.
Usually I develop new module along with writing corresponding "Test"-program. That allows me to test and debug module functionality during its development. I create a batch that compiles the test program and runs it if it compiles with no errors.

I guess you start with writing module in full (though compile it during development) and only then write a test program and begin debugging. That's different development style, which of course is a personal preference.
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).

BTW, talking about modularity.
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.
Post 29 Dec 2009, 01:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
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.
Post 29 Dec 2009, 01:59
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
booter wrote:
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.
Yes, I think with fasm it would be very difficult. I think you are talking about namespace separation, right? This is where you would need to move to a linker based setup. Assembly is not really suited to full compiles with the namespaces separated. All labels are global so trying to hide things is impossible.
Post 29 Dec 2009, 02:08
View user's profile Send private message Visit poster's website Reply with quote
booter



Joined: 08 Dec 2006
Posts: 67
booter
revolution wrote:
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.

You suppose that choise of which modules can/should be used is up to developer of the moule. Though that's common practice, I highly discorage it. In my opinion, program/system structure (modules, their functions and dependences) should be definned by the system architect (may be se same person, though). With this approach discovery that ("B then changes and now needs D and not C") means faulty design of the system and most probably would require massive changes anyway.
I require all dependences of the modules to be well defined beforehead and that makes it natural to have all "include" statements in one place and ordered properly. With my approach the module itself does not care about the structure of dependences. If this module is included in a "wrong" place (i.e. includes are not ordered properly) you get compilation error.
Post 01 Jan 2010, 00:44
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
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.
Post 01 Jan 2010, 01:38
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
yeah revolution, but if they take more time to be more organized, then the project would attract more newcomers (to code) which otherwise would get terribly confused at the code without knowing the details.
Post 02 Jan 2010, 20:02
View user's profile Send private message Reply with quote
booter



Joined: 08 Dec 2006
Posts: 67
booter
revolution wrote:
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.


Things start to get confusing when you introduce changes without providing backward compatibility. Changes inside the module should never require changes anywhere else.

Freedom to include whatever you want/need leads to progressively less manageable system (as it happened with MS Windows), see
http://www.windows-now.com/blogs/robert/mark-russinovich-explains-minwin-once-and-for-all.aspx
Post 03 Jan 2010, 09:23
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.