Hello again, I'm more or less certain that this has been discussed before sometime but I seem not to be able to find it. How do I split my asm files up? I want to have a Main file doing only the Initialization, then I'd want to have a WndProc file, a Macros file, a Little Procedures file &on &on... So that I'd be able to keep everything nice and clean. I used already a file where I always inserted my texts and included it in my includes which always ran just fine. But when trying to split everything up I don't know what to include where ??? Either way I get symbol redefinitions or I get funny error messages like: * cannot have implicit far jump or call to near label * use of register assumed to ERROR Can someone guide me thu this or show me an example? I don't want to deal with scrolling 5-10 pages up anymore only to insert a new constant.. Life would be so pretty if I'd could just switch to another file add something and that'd be it. TIA, JimmyClif
Posted on 2001-02-24 11:08:00 by JimmyClif
There's a few ways you can split things up, depends on how 'reuseable' you want the seperate files. The simplest way is to just write each seperate piece as if they were all part of the same .asm file. You start with one main .asm (the one you compile), and in it's INCLUDE section you drop the sub-files. I use .inc extension for the sub-files. Simplest way to split large projects, and you don't really have any extra management beyond the include lines in the .asm. (Sorry, I don't know any published examples) The next way is good if these files are to be reused over several projects. If this is so, you probably don't want them making .code or .data unless you explicitly want this. So, to turn things on and off, define each subgroup as a macro. INCLUDE them as before, and then reference the macro where you want it. /masm32/macros/MACROS.ASM works this way. The ultimate way to do this is write the code sections as library modules. Libraries do their magic at link time, they are precompiled groups of code that the linker adds to your final product. Items inside the lib to be assessed from outside (ie, from your program) should be marked as PUBLIC for procs, and externdef or PUBLIC for variables. The data items to be used in your .asm are marked externdef (which needs a size parameter too so the compiler leaves enough room for each). The aim is to define each piece as small as possible. Each piece gets it's own .asm file. It is not crazy to have a .asm file that just defines a single byte if the need be. My next revision of CoLib will have 3 modules that each just define 1 GUID (a data structure). This is so someone using the lib can just use it to define that one thing without importing the rest, as the lib will pull out the whole compiled .asm file if anything in it is referenced. Libs need to be built just once (assuming all that code works). However, this build can take a substantial ammount of time if each .asm making up the lib references windows.inc (parsing windows.inc is responsible for the majority of compiling time). Since my CoLib needed just a handfull of windows constants, I made a seperate .inc file named mini_win.inc to reference these, it builts everything (some 30 files) in a flash. Check either my CoLib (latest masm service pack) or the masm32 lib as examples.
Posted on 2001-02-24 11:42:00 by Ernie
well, i do that : code your thing then take a part, for example wndproc, in a wndproc.asm file and at the position wanted in the file, write :
include wndproc.asm
basically, u just write all your files, and include them just where u want in the code by putting a include myfile where you want
Posted on 2001-02-24 15:39:00 by roy
I touched base briefly on this topic about a week ago. I discovered that there is good examples of how to break the code apart simply using Prostart.exe that comes with MASM. Use prostart, and include only a Button control. then open up all the asm files and study the organization. It basically follows what Ernie stated, but it does give you a feel for how and when .code and .data gets used though out the project. I believe it's goes: Main.asm --> Main.inc -- >>> all the separtate.asm's (like Buttonctrl.asm ~ or whatever its called). It also shows how to hide the PROTO for each fuction such that you only need to include a file (all the dirty work is done..) NaN
Posted on 2001-02-24 15:48:00 by NaN
I always had problems with using data/procedures globally through all files. I tried to make one main.asm which includes other files, but I never succeeded in making it work. I couldn't use the variables declared in another source file when one source file was included later than the other. I've once made a utility that combines serveral source files to one main file (it combines the seperate sections (.code/.data) and moves everything to the right place. Then the main source file can be assembled as if you have written only one file. This worked a lot better for me but I may have forgotten something with the other method of including files. An annoying problem with the utility is that the line numbers given with errors by masm are line numbers in the main file, not in the real source files. You can download the util here (rename the .bin to .zip, my server somehow seems to have problems with zip files), the description and manual are at my site. Maybe it's of some use to you. Thomas
Posted on 2001-02-24 16:41:00 by Thomas
What this place needs is a good tutorial on creating a library. In the meantime, you can look at the \masm32\m32lib\ masm32 library. The .asm files and the lib make file are there. You probably all have it, and can see how the files are laid out, how procs are defined, how variables are shared (IMalloc.asm creates a public variable). If I get some spare time (yeah, right) I'll put this tut at the top of my list.
Posted on 2001-02-24 17:05:00 by Ernie
Jimmy, Most of what you need to do here has already been said and there are numerous ways of doing what you are after depending on the size architecture you are after. I agree with you about breaking up a project as it makes navigation simpler and faster, particularly on a larger project. The simplest method is to use the "include" directive with source files but what you must make sure you do is not "forward reference" information that you need in the program. Usually what you need to do is be careful about the order that you include source files and this is best done at the beginning of one file. You include any MACRO file so it is available for any other part of the program after it, then the system include files and their matching libraries. You can then write source in different files and use include with them. This is a good architecture for the CORE code of an application as you can have global variables that can be called from any part of the code. To extend this into a larger project, you start to write modules which can either be built into libraries or linked directly when you build the application. Modular programming in the form of libraries and linkable modules is the basis for very large scale applications. In the small editor in MASM32 is a plugin DLL that will start a module for you and it has the correct format to build either a library or a linkable module. Usually when you build a library module, you assemble it into an OBJ file and then use either the LIB driver or LINK directly to build a library. The format is in the batch file MAKE.BAT in the m32lib directory and it is easy enough to use once you get your modules working correctly. Modules differ to the extent that they are not part of the CORE code of the application as they do not have the scope to use variable declared in the CORE code. This allows you to fully encapsulate reusable sections of code. Good luck with your project. hutch@pbq.com.au
Posted on 2001-02-24 17:45:00 by hutch--
there is a way using public WndProc extrn TestString:byte where public defines a procedure in this part, that should be available to all parts, and extrn says that the string of bytes called TestString is actually stored in another file. Then you link them all together, and the linker sorts out the external references.
Posted on 2001-02-24 21:16:00 by mega
I don't know if anyone is interested but, I have been writting a IDE that loads Masm32 by hutch ASM files and has a menu that shows all the procs in it. infact the edit windows only shows the proc you are in, to move to another proc you just select it from the drop down menu. This IDE is not done yet it will compile same as qeditor ect. I am still working on it. I can give what I have so you all could give me some advice on what you would like to see it do, ect. If anyone is interested please let me know and I will post it on my site.
Posted on 2001-02-25 13:22:00 by Zcoder
I'm still looking for a painless solution, i.e. using multiple source files and assemble them as if they were one. All of the methods described need additional things to do to make it work. With including files, forward references won't work. The use of public/extrn will work but you need to define the external data/procedures every time you need them. The lib method is on itself a very good method, it's very good for large projects and portability, but even for small projects I like to have multiple files with data/wndproc/main etc. without creating a lib. My utility (combiner) isn't perfect either, although it makes masm really treats it as one file (because it is :)) but masm has no idea about the original files so all the errors will refer to one file. Anyone more ideas on a simple solution? Thomas
Posted on 2001-02-25 13:50:00 by Thomas
I think a nice tool for an IDE would be anutomatically creating PROTO's for a project. We could just use includes and forward referencing wouldn't be a problem. bitRAKE
Posted on 2001-02-25 14:49:00 by bitRAKE
Yes My IDE will be made to make new PROTO's and proc's, a pupup window will ask for the name of the new proc and the names of any, if any Param's to pass to it and to define them as BYTE, WORD, DWORD ect. then it will write the proc with the endp ect, and place the new PROTO for it in the right part of the source. all you have to do is write the procedure. if anyone has any comments or IDEA's on this IDE I sure could use some feed back to make this IDE easier to use, and take the mess that newbies seem to get swampt with like a large ASM file with to much to sort out.
Posted on 2001-02-25 15:09:00 by Zcoder
yeah... all that will be nice....on the end of that road is VB an VC++ remember that we should keep it simple and raw...asm is about that is it not?...dont make me wonder what did i wrote in the program and what did the IDE wrote...too much... easy to type and asm dont allways work together :D... but i will agree on any ideea that can help us work little but in the same time dosent separate us from the machine bare facts/bones too much... again i dont want to make it like we work easy and the program that rezults is a bloatware... also if an IDE will not allow me to edit/see the source file "as it is" and will only show me one procedure at a time (VB style)..i will drop it at once...no questions asked... making things EASY and FAST and TOTAL CONTROLL and RAW/BARE is a hard job and not allways posible in the same time
Posted on 2001-02-25 18:29:00 by BogdanOntanu
Wew... thanks a lot for the guidelines. Alrighty.. I guess I worked it out now... I did split my files into 6 new ones... Unfortunately I made in, every new file a .code (and/or) .data section but: "What the heck?" It works :) I used the include statement and included them all after a mind-breaking sorting out. But finally I made it: * Main File, Protos, Includes, Constants, Data, Data?, Little Procs (Because the Little Procs are used in the WndProc),WndProc As said: At assembling time (I tried inserting a voluntary hWWnd somewhere) it only gives me an error in the Main File at the exact line where I included my Main.inc file... and I wonder if this could be a problem soon?) (Sidenote: I really wonder how Bogdan does it with his 1000 files???) But anyways... I definitively try out the other ways described here and keep you guys informed. Thanks, JimmyClif (in search of the cleanest solution *g*) This message was edited by JimmyClif, on 2/26/2001 3:32:00 AM
Posted on 2001-02-26 03:31:00 by JimmyClif