I'm writing a program that gets bigger every day (of course). But I feel dirty about putting everything in one .asm file (besides the .dll).

A.) When should I use more than one .asm & .obj file?

B.) How do I implement such a thing? Including linking and coding.

Thanks again for the seemingly infinte knowledge found on these boards.
Posted on 2001-10-28 14:15:10 by lackluster
I develop in VB for a living, that means lots of different files in any one project :) However, with my asm stuff, i usually put the function declares in one file, the include statements in another, and the global data declares in a third. If the main file is still getting too big, i then move completed parts of the code to another file, but this is just so i don't have to scroll through heaps of code all the time, once i finish the app i move all the code back into the same file again.

It will be interesting to see what habits other people have :)
Posted on 2001-10-28 14:32:14 by sluggy
Heres how i do a basic window.
Posted on 2001-10-28 16:02:35 by ChimpFace9000
sluggy, That what I do. I'm pass 12,000 lines of code and when I'm finish Next Year it all goes to one NutShell.

ChimpFace9000 What the deal with 003.zip there is not .lib files. Is this a better way to code or what. Will it save steps or stay safe. I want to know. I'm now concern about making my app hard to crack so the writing style may be an very imortant thing. I have no problem moving to a better style of coding.. My style now has always been Icz Style but that was design to learn with I MAYBE. Thanks
Posted on 2001-10-28 16:59:51 by cmax

You have a number of options to stop a program from getting too big. The "include" syntax in MASM allows you to write multiple files and simply include them in a main file.

For larger size apps, you can build a library and have the finished pieces of code linked when you build the program.

You can use the older technique of writing seperate modules and writing the link syntax in a batch file or make file and link it manually at build time.



PS : When you find that source of infinite wisdom, let us all know so we can go look for some of it. :)
Posted on 2001-10-28 19:01:51 by hutch--
The feeling I get here is that it's OK to have a single huge .asm file. Is this correct? I was under the impression that it would increase performance to have sepearte .obj files for say each main window or something. I suppose the way I'm writing it is fine in that case. Thanks.


PS : When you find that source of infinite wisdom, let us all know so we can go look for some of it.

That's why I put the seemingly clause in :grin:.
Posted on 2001-10-28 21:02:03 by lackluster
INCLUDE files:
All the files are assembled in one run into a single object file.

OBJ files:
Files are assembled in separate runs of the assembler, generating separate object files.

LIB files:
Similar to object files, but can contain information about exports in other programs. These files are generated by the linker from object files and export definition files.

DLL files:
The executable remains in pieces. Created by the linker.

All these methods can be used all at once: DLL(LIB(OBJ(INCLUDE)))) There are priority levels within the linker that specify linkage with libraries and object files. Breaking a program into pieces requires some planning at higher levels. Personally, I've been playing around with a few levels at a time until I get a feel for the whole scale of abstractions.
Posted on 2001-10-28 22:29:03 by bitRAKE
I prefer "a bunch" of asm files (or C, for that matter), that are
assembled into separate .obj files, and finally linked together. If I
have a lot of files with sort of similar functionality, I might make a
lib out of them.

This approach is pretty neat, if combine with makefiles, since you
only have to re-assemble the files that you have actually changed,
instead of the (imo) stupid "include" approach where you always
go through the entire set of code lines.

What to split files by? I keep one file for each dialog or wndproc.
When I have to use global data, I use a file for that (and a header
file telling that "hey, we have this data that is in another obj").

I also try as much as possible to separate the functionality of my
apps from their GUIs, where that makes sense. Ends up a lot cleaner,
easier to read and extend. For me, at least.
Posted on 2001-10-29 00:00:31 by f0dder