Questions about assembling and linking

[Queue]

So, my first post looks like it's gonna be an avalanche of questions. I think some of these questions are a tad above the beginner level, but this forum seemed suitable as I'm learning the intricacies to working with MASM.

Now, the subject is a little misleading; I'm not having any trouble assembling or linking programs. What I want to know is some of the details about what goes on in each case.

1) Are module-definition files (.def) used by modern executables (as opposed to DLLs)? I want to know if I can check for the presence of a .def file before linking to heuristically determine if the object files should be linked as an EXE or a DLL. Basically, if .def files are more commonly used by EXEs than I've seen, I don't want the presence of a .def file to default to linknig as a DLL; otherwise, I do.

2) When you link multiple .obj files, does the order that they're sent to the linker matter? What about when you link files using a wildcard (*.obj for example)?

3) Why is rsrc.rc such a common name for a resource script file, rather than Project_Name.rc?

4) When comparing LINK.EXE and POLINK.EXE, it seems like LINK.EXE is giving the resource section 4 bytes more than it needs to (as specified in the PE header where the size of the .rsrc section is defined); is this the only major inefficiency in LINK.EXE, aside from the Rich header?

5) Why, among MASM32 projects, is it so common to specify includes with \masm32\etc. rather than using INCLUDE and LIB environment variables (set to the respective MASM32 folders), and then using path-less include and includelib entries in the ASM file?

I think that covers everything I can think of at the moment. I'm pretty new to MASM (well, assembly in general), but have had a pretty easy time working with it and have particularly enjoyed experimenting with building tiny executables and simple utilities. However, the more I've used it, the more I've wound up considering things like the questions above.

Queue

[clive]

1) Perhaps, although it is possible to export functions/entry points from an EXE.

2) I don't think most application/tools accept wildcards unless linked against setargv.obj
The link order will define entry points, order of code/data within the file, and segment order and alignments. It's probably less problematic in 32-bit code, but things could get very weird with 16-bit code.

3) Hard to say, some applications have defaults, I've never used this naming.

4) What version, there are dozens on versions of LINK, and Microsoft has changed alignment and PE structure ordering over the years. LINK can make very compact files, however you might limit OS compatibility if you get stupid over a few 4K pages.

5) Probably because people don't use command lines like they used too, and the environment variables all seem to get cluttered. I host several compilers and assemblers, and use BAT files from the command line to set the appropriate environment for the specific tool chain. You should do what works for you, don't be bound to what others do.

[theunknownguy]

1) Are module-definition files (.def) used by modern executables (as opposed to DLLs)? I want to know if I can check for the presence of a .def file before linking to heuristically determine if the object files should be linked as an EXE or a DLL. Basically, if .def files are more commonly used by EXEs than I've seen, I don't want the presence of a .def file to default to linknig as a DLL; otherwise, I do.

Seems no difference at the time they are on export section... Also the same goes for imports. (correct me some one if i am wrong)

The link order will define entry points, order of code/data within the file, and segment order and alignments. It's probably less problematic in 32-bit code, but things could get very weird with 16-bit code.

On C++ compilers ive saw the vector initialiser of each class are put next to other, no matter the order you pass the sources... (correct me again if i am wrong)

[jj2007]

3) Why is rsrc.rc such a common name for a resource script file, rather than Project_Name.rc?
..
5) Why, among MASM32 projects, is it so common to specify includes with \masm32\etc. rather than using INCLUDE and LIB environment variables (set to the respective MASM32 folders), and then using path-less include and includelib entries in the ASM file?

3) Organically Grown Habits^TM.
Pro rsrc.rc:
1. You can save your project as project_22June.asm, project_23June.asm etc, and always use the same resource file
2. Your batch file looks a little bit simpler.

Contra rsrc.rc: You need a new folder for each tiny "project"

In RichMasm (my RTF editor) I use Project_Name.rc as default, but with a simple OPT_Res FileXy somewhere under end start you can define a "fixed" resource file.

5) It works flawlessly, especially if people respect that \Masm32 is more "compatible" than C:\Masm32\
Setting environment variables is pretty clumsy, and has changed with every major Windows version.

[Rockoon]

#5 bugged me when I re-downloaded MASM32 to assemble some testbed code here. The source files for the testbed were on another drive. Even though I "fixed" the include path to an absolute drive specification in the testbed, that include file included another, and of course didnt have an absolute drive specification....

Thinking about it, there isnt really a good solution. Note that this fact also prevented the MASM32 IDE from assembling the file (with no error messages.. either... hrmf)

[jj2007]

#5 bugged me when I re-downloaded MASM32 to assemble some testbed code here. The source files for the testbed were on another drive.

Hey Rockoon, having too many drives is a typical nerd problem. But then, we probably all qualify for that title here :bg

[Queue]

Some of these questions are in regards to me setting up a system to automate assembling and linking (particularly other peoples example code).

For example, I think it's fair to assume that if a .def file is included, the ASM file is for a DLL. Now, I know an EXE CAN use a .def file, but even a bare-minimum one (only a NAME entry) will change the resulting EXE, and, according to Microsoft, ''If you are building an .exe file that has no exports, using a .def file will make your output file larger and slower loading.'' http://msdn.microsoft.com/en-us/library/28d6s79h(v=VS.80).aspx

But I asked just in case anyone had thoughts on such an assumption.

My solution to people using all sorts of screwy folder structures for includes was to make an ASM file preprocessor (well, and a resource script preprocessor) that reduces includes down to just their file name, and make sure I have INCLUDE and LIB environment variables set properly. But again, I wanted to ask why people don't just do it that way by default in case someone could share some insight.

jj2007, adding directives after the end statement is pretty darn clever. I've been toying with using echo's in the ASM file to issue build directives. My way is clunky but pretty capable since I run the output as a batch file.

clive, when I referred to LINK.EXE, I just meant the version from MASM32, so 5.12.8078.

Queue

[theunknownguy]

Some of these questions are in regards to me setting up a system to automate assembling and linking (particularly other peoples example code).

For example, I think it's fair to assume that if a .def file is included, the ASM file is for a DLL. Now, I know an EXE CAN use a .def file, but even a bare-minimum one (only a NAME entry) will change the resulting EXE, and, according to Microsoft, ''If you are building an .exe file that has no exports, using a .def file will make your output file larger and slower loading.'' http://msdn.microsoft.com/en-us/library/28d6s79h(v=VS.80).aspx

I guess they mean adding a .def file would write into your export section the export name and the ordinal number. Wich would make your output file larger (lol not that much) and when load will check for export section RVA.

Its a fair assumption but who uses a .def for EXE?

Also here is a good guide about PE format including at first the EXPORT section:

http://msdn.microsoft.com/en-us/magazine/cc301808.aspx

[Rockoon]

EDIT: Woops, theunknownguy basically beat me to it.

[theunknownguy]

EDIT: Woops, theunknownguy basically beat me to it.

Lol i hate this nickname...  :(

[redskull]

But again, I wanted to ask why people don't just do it that way by default in case someone could share some insight

Most newcomers know nothing of environment variables or path settings, and it's much easier to say 'install to the default directory and build with the default options", rather than walking them through painstaking setting (and resetting) the paths.  However, you can do some pretty impressive stuff with NMAKE, if you're willing to invest the time.  For example, you can get the current drive and directory via an mnake macro, and and pass a new INCLUDE path to ml via the /I switch when you build the file, or even set (or reset) the INCLUDE environment, etc, etc.

-r

[Queue]

I would love to see an example for dynamically setting the PATH, INCLUDE and LIB environment variables using NMAKE. I'm doing as much, but with a monster of a batch file (for example, setting the INCLUDE folder to be %0\..\INC, which means a subfolder named INC under the folder my batch file is in). My solution works, but I'd love to have more options to explore.

My system for assembling and linking is a Frankenstein's monster, that's for sure. The backbone is a heck of a batch file: it can handle an ASM file drag-and-dropped onto it, being called via a file association (I have ASM files set with an Edit command for notepad.exe and a Compile command for my batch file), being called via another batch file sending a commandline argument, or being called via another batch file with the project name in an environment variable. The ASM and RC pre-processor is a vbscript file that's called by a miniscule MASM-built EXE and it relies on Vortex's Scan.exe and inc2lib.exe (which relies on POLIB.EXE) to generate missing .inc and .lib files on demand. I just use Microsoft's ML, LINK, RC and CVTRES to do the actual assembling and linking.

Although I have decent error-checking to make sure everything is working, NMAKE would surely be a better fit for huge projects.

Regardless, I need to reconsider how I handle linking my object files; I'm currently doing it via "Project Name.*.obj" and my batch file generates "Project Name.res.obj" (if "Project Name.rc" or rsrc.rc exist) and "Project Name.asm.obj" but if I want to include additional object files, I don't have control over what order they're linked in.

theunknownguy, that's a great link; thanks.

Part of what got me to develop an automated system for assembling and linking for myself was MASM32's installation location being a folder on the root of my drive. -_- I love the resources that MASM32 provides, but there's no way I'm gonna let it tell me where it's going to be installed, especially if it's not under Program Files. Personally, my C drive has the following 4 folders and nothing else: Windows, Program Files, My Documents, Recycled. My D drive has Program Files, My Documents and Recycled. I'm the type that only puts one partition per physical drive, and keeps folders and files extremely organized, in particular I keep root folders of drives tidy and my Desktop, Quick Launch and Start Menu are near empty.

Queue

[redskull]

NMAKE can build on "psuedo targets", which are just file that don't exist (and are always 'built').  For example:

all: setenv myfile.exe

myfile.exe: myfile.asm
   command_to_build file

setenv:
   SET INCLUDE=SOMETHING_OR_OTHER

'all' is a pseudo target, which depends on 'setend' (another psuedo) plus myfile (the actual output).  Both of them are evaulated as to the other blocks, and so on.  Moreover, you can use the $(@D) Macro to expand to the current directory:

setenv:
   SET INCLUDE=$(@D)\SOMETHING_OR_OTHER_IN_WHATEVER_DIRECTORY_I_WAS_RAN_IN

and so on.  makefiles are WELL worth the investment into learning them, especially if you build from the commandline.  The best guide is chapter 16 of the masm programmers guide, available all over the place.

-r

[Rockoon]

Hey Rockoon, having too many drives is a typical nerd problem. But then, we probably all qualify for that title here :bg

After thinking about this more, I just dont see why any of the include files distributed with MASM32 have hard-coded paths in them. This *negates* those environment variables, boiling down to two obvious limitations:

* cant assemble across drives while referencing any of those includes containing hard-coded paths
* cant install masm32 to a different location (ex: D:/assemblers/masm32)

There could be other issues. For certain, QEditor breaks (without notice) when dealing with a source file on another drive that includes one of these offending include files. The one that caused me issues was \masm32\include\masm32rt.inc


For those that use the command line (like me), MASM32 can create a shortcut to CMD.EXE upon installation, essentially this would be the "MASM32 Console"
..this shortcut is basically:

Target: %windir%\system32\cmd.exe /K "environ.bat"  
Start in: D:\masm32\

/K tells cmd.exe not to exit when done processing the command it was given, the D:\masm32\ is replaced with the install location at install time, and ENVIRON.BAT is:

@SET PATH=%CD%\bin;%PATH%
@SET LIB=%CD%\lib
@SET INCLUDE=%CD%\include
@ECHO MASM32 Console.
@ECHO ------------------------
@ECHO Run 'QEditor' to use the Integrated Development Environment.


Thing like this "MASM32 Console" (and NMAKE solutions) are useless as long as those hard-coded include paths remain.


Edited to add:

The current situation ISNT newbie friendly. I am much less likely to help someone if I cant get their code to assemble without a lot of work on my part, so I must choose between "use the default install location which I dont like" and "dont help people"

[Rockoon]

Thinking about this further, that environ.bat could just as easily be IDE.BAT:

@SET PATH=%CD%\bin;%PATH%
@SET LIB=%CD%\lib
@SET INCLUDE=%CD%\include
@start QEditor
@exit