I just finished a new version of my combiner program. It takes multiple asm source files, splits them into their seperate sections (.data/.code etc), then puts everything in one file, which you then assemble. The advantage of this program over the known methods like making one file that includes the other files or assembling them with *.asm is that there won't be any errors about forward references or unknown data etc. Data can be used in any source file and be accessed in any source file without writing a single line extra. The first versions of my program had one big irritating disadvantage. Because everything was merged in one file, masm treats it as one file (which is good) but also gives the errors with line numbers in one file (which is not good :(). I know solved this problem, it creates a line information file with information about the real source files. Then there's a small program, mx.exe, which you can use as if it were ml.exe. This mx.exe just runs ml.exe as if you used ml.exe, but translates the output of masm by using the line info file. It will fix the real source filenames and line numbers. I mainly created this program for myself, but if anyone is interested in it, you can download it here. There's no documentation yet (although there are docs on the earlier versions at my site), but it includes a demo to show you how it works. Full source code is also included. Thomas This message was edited by Thomas, on 3/18/2001 2:09:46 PM
Very interesting idea. However, after messing about for several months trying to get ways to SPLIT large projects, I'll probably not sample your application. I'm actually splitting files that need not be split just to follow a general scheme of code confinement or encapsulation (ie, certain information in the program shall not be directly accessable from other parts of the same program). This isn't very hard to impliment. The hard part is figuring it out for yourself. It's a problem with no tutorial
since any good tutorial should be a short subject on a single topic.
To split, you start with a blank .inc and .asm file. As you define items in the .asm you wish shared, you declare them (for equates) or externdef (for variables) or proto them (for procs) in the .inc file. This .inc gets included in that same .asm file, and any other .asm files in your project.
Quick Editors default build bat files will even work with such files if you build each .asm seperately. Building on *.asm and linking on *.obj also works fine.
So far, I've yet to hit any forward reference problems, so I'm not shy of the problem you solved. But people have their own styles of work, and if this suits you, congratulations on making yourself a nice tool.
"Aw, being a clown sux. You get kicked by kids, hit by dogs, and admired by the elderly. Who am I clowning? I have no business being a clown! Iím leaving the clowning business to all the other clowns in the clowning business."
It seems Ernie and I have much in common in many ways... I may not have his vast intellect when it comes to the internals of COM, but I'd agree that we agree on encapsulation, object methodologies, and big projects being smaller files and so and so forth... all this came from experiences and past projects (work) and just understanding computer science and programming in general... for every advantage, there is a disadvantage, but every advantage, for outweighs the disadvantages. My own opinions, are that each person has their own style and preference of how things are done. I, for one, greatly avoid single large files when working on projects. Too many problems, gobals here, globals there, and hard to find bugs (usually). I see it's use, however, when compiling, it's easier to build one file. However, Borland found a solution to a problem that I intend to implement in the IDE I'm working on: when using many files, only compile the one's that need to be. That means if I have 45 files in my project and maybe 1-3 inc's, and only 3 files change, I only need to compile the 3 and link them together. This saves compile time and helps you make the project (er, files) incredibly more usable if you ever need to use that file again (if for somereason you don't just use the lib)... Doesn't mean I won't try the program. It has it's uses. However, I take a much different approach. But then again, maybe there's something I can learn from having all the files merged into one... never know unless I try... :) Thanks, _Shawn
I just wanted to know why the Mosaic program tried to write to my win.ini file??? I have top security in my system, as I am also a sever for my websites, and it stopped and reported to me about this acurance with this program.... I just want to know what it's purpose is to write into the win.ini file? This message was edited by Zcoder, on 3/18/2001 10:06:25 PM
Ernie,Shawn: I agree with you that it is useful to create seperate source files that work as independent as possible, this gives a better reusability and the project is nicely structured. But when I create a seperate file with data that is used in multiple files, I should externdef everything in the data file to use it. I wanted a clean solution that makes it possible to use data, procedures etc. troughout the whole project without defining anything. But as Ernie said, everyone has it's own way of doing things, I created this program for myself in the first place. Zcoder: The demo should not write to win.ini, maybe some API the program uses tries to write something but I would have no idea which or why. Anyway, it was not intentionally. Thomas
I see it's use, however, when compiling, it's easier to build one file. However, Borland found a solution to a problem that I intend to implement in the IDE I'm working on: when using many files, only compile the one's that need to be. That means if I have 45 files in my project and maybe 1-3 inc's, and only 3 files change, I only need to compile the 3 and link them together. This saves compile time and helps you make the project (er, files) incredibly more usable if you ever need to use that file again (if for somereason you don't just use the lib)...Isn't that what MAKE does?? James