Questions about assembling and linking

[Queue]

That's what drove me to make an ASM file preprocessor Rockoon; it parses an ASM file reading each include and includelib line, checks to see if the specified file exists, and if it does, it changes it to JUST a filename with no path at all. Then it checks a couple different folders for the file (the current working directory and the path specified by the INCLUDE/LIB environment variable). If it's still not found, then it tries to generate the file automatically. So far I've been able to assemble and link, without modification, basically every bit of code I've found attached on these forums, and several different MASM tutorial code sets (Iczelion, td_win32asm).

I largely started this thread to try and get info to refine my system further. The easier it is for me to build peoples' example code, the easier it is for me to work with and learn from it.

Queue

Edit: I had to modify masm32rt.inc to remove the hard-coded paths as my preprocessor only handles the main ASM file, not the includes. It and macros.asm are the only two MASM32 includes that have hard-coded paths in them, aren't they?

[redskull]

The current situation ISNT newbie friendly

There's an obvious solution: install to the default directory and build with the default options!  :green2

But for real, look into NT 'junctions' - you can just hardlink one path with another, and solve all the problems at once

[Rockoon]

The current situation ISNT newbie friendly

But for real, look into NT 'junctions' - you can just hardlink one path with another, and solve all the problems at once

It is still the case that even with the junction HACK, cross-drive assembling is still broken, unless you propose creating a junction on every drive?

This is the most serious of the issues. That newbie that we are worried about, even if (s)he installs to the default and recommended location, (s)he will still eventually (maybe immediately) run into the cross-drive problem.

As I have noted before, qeditor remains completely silent about the problem. No error messages, no indication of any problems whatsoever. No executable generated. No object file generated. Silence. That is most definately NOT newbie friendly.

So the whole thing is circular.. hard coded paths BECAUSE of newbies, and then slug newbies in the face BECAUSE of hard coded paths.

Just get rid of the hard coded paths. If it means environment variables, there are simple newbie friendly solutions for that.

[dedndave]

i prefer using the environment to control assembly
in my opinion, it is how it was meant to be used
and, it allows you to easily switch libraries, etc
but, there are 2 problems if you want to use that technique with the masm32 package

1) you'd have to change a lot of files to make it work   :P
and, you'd have to do it each time the package was updated
you could probably write a little program to do it for you, though

2) code you authored would not be usable in the context of the forum
most other forum members are set up to use the hard-coded paths
if you wanted to post code or example programs in the forum, you'd have to modify them each time in order for others to use it
this would open up a lot of opportunities for errors

apparently, some of the inital users were confused by the variables
that meant there were problems setting up the package in the beginning
Hutch wanted the package to be a simple "install and use it" type package
thus, we have hard-code paths

[GregL]

But for real, look into NT 'junctions' - you can just hardlink one path with another, and solve all the problems at once

For Windows Vista and Windows 7, a directory symbolic link will work just as well (see the MKLINK command), I do that with my source code on my D: drive and it works just fine.  For earlier versions of NT based Windows you will have to use a junction.

[Edit] You can use Sysinternals junction.exe to create a junction.

Examples:  D:\MKLINK /D masm32 C:\masm32

                    JUNCTION D:\masm32 C:\masm32

[Rockoon]

2) code you authored would not be usable in the context of the forum
most other forum members are set up to use the hard-coded paths

Source code that references the include files in a hard coded manner may fail to assemble, but only if the user has put them someplace else, and then the source code that has failed to assemble can be modified.

Source code that references the include files in a soft coded manner may fail to assemble, but only if the user doesn't have environment variables set up, and then he can edit the source code, or modify his environment variables, or even supply the correct path to the assembler on the command line.

The alternative situation is that the include files themselves use hard coded paths, and if the source code doesnt assemble because of it, the user has to edit or move the include files! That could break other source code!

All bets are off with regards to interoperability as soon as the user is coerced into messing with those supplied include files, which must remain unchanged and unremarkable if we desire interoperability.

Let me re-iterate that qeditor will not assemble a source file located on a drive where masm32 does not reside, unless that source file does not reference any of the offending hard-coded-paths-inside include files in any way. Furthermore, qeditor could *easily* supply the proper environment variables. This insistence on hard coded paths is completely irrational:

A development console could be easily supplied that has the proper environment variables.
qeditor could easily be modified so that is produces the proper environment variables.
make.bat templates could easily be given that include the proper command line to locate the include files.

hard coded paths that are NOT in include files are NOT the problem.

[Tedd]

The correct solution is to just modify the .bat files so they include "/I<include-path>" for ml, and "/LIBPATH:<lib-path>" for link. 'include' and 'includelib' statements then require no path (just the bare filename), and everything works no matter where anyone has masm installed.

..as long as the .bat paths are set correctly, which could easily be produced on install; or they can use %MASM_HOME% and its value could be set once upon install.

[Queue]

Only masm32rt.inc and macros.asm contain \masm32\ includes, and the one in macros.asm is pretty insignificant (the uselib macro). So, if you want to use MASM32's includes from a non-default location, modify masm32rt.inc yourself and you'll be set.

After some more tinkering I've set myself up thusly:
- MASM folder containing BUILDASM.BAT
- - BIN subfolder containing programs for assembling, linking, etc.
- - INC subfolder containing .INC files, macros.asm and resource.h
- - - LIB subfolder under the INC subfolder containing .LIB files

Now, the first odd thing you'll notice is I put the LIB folder in the INC folder, instead of beside it in the MASM folder. This is so I can use a trick to save environment variable space. Instead of defining my INCLUDE and LIB environment variables at the same time, I only define INCLUDE. After assembling, but before linking, I use a single line in a batch file to set the LIB environment variable to %INCLUDE%\LIB and empty the INCLUDE environment variable, which effectively renames INCLUDE to LIB and adds \LIB.
The following two lines are the same number of characters as eachother:

Code Select Expand

INCLUDE=X:\Folders\INC
LIB=X:\Folders\INC\LIB

Why do I go through that trouble? By default, Win9x has really limited environment variable space, and one of my computers is still running Win98SE.

The batch file assumes everything it will need is in the BIN subfolder, so it sets that PATH environment variable to that folder exclusively.

I've got this working off a flash drive, so I wanted it to be capable of setting environment variables on demand, and I had to do a fair bit of weird things to get the batch file to behave consistently on Win98SE, XP and Vista, but as is, I can now plug in to any given computer, drag-and-drop ASM files onto BUILDASM.BAT and have them assemble and link properly. To save space, I only include the .INC and .LIB files that are in masm32rt.inc; all others are generated on demand by my VBScript ASM file preprocessor (and Vortex's Scan and inc2lib utilities, and POLIB). Obviously, that only works for import libraries and not libraries that contain actual code, but that accounts for most of them.

In relation to my original 5 questions, and some of the feedback I got, I've done the following:
1) If a .DEF file exists with the same name as the .ASM file, assume we're making a DLL, and link with the appropriate settings.
2) I haven't improved object file linking order, right now it's using a wildcard to make sure it gets any that exist within the naming scheme I'm using ("Project Name.*.obj") but this doesn't let you specify the order.
3) I simply check for both "Project Name.rc" and rsrc.rc; that covers both situations.
4) I'm still using LINK by default for now, rather than POLINK, but I have POLINK and found the output it generates easier to hex edit by hand than LINK's output.
5) A manually edited masm32rt.inc plus an ASM preprocessor handles the \masm\etc include and includelib entries, in addition to any ASM files with completely hard-coded include paths (C:\etc).

I think in the case of number 2), the only real solution is manual linking; I can't think of any way to determine a ''proper'' link order for object files.

Queue

[dedndave]

well - we aren't talking about all that much environment space
that is, unless you use some really crazy folder names   :P
but, you can enlarge the environment table in DOS and Win9x
i used to set my MASM 5.10 up with permanent variables
LIB and INCLUDE are the important ones
of course, your BIN folder should be in the PATH variable
MASM was another variable that pointed to the BIN folder, also
i don't think they ever made a special one for MACROS - i used to put macros in with INC's

you can also set them up temporarily
in fact, you can create a special ASM Command Prompt (console window) shortcut with the variables all set up
that way, you don't have to put them in every batch file - only the ones where a change is made
if you wanted, you could have seperate shortcuts for assembling with different paths
i used to do something similar back in the days when the C compiler paths conflicted with the MASM paths
the environment table space is only used when you have that console window open

[theunknownguy]

This is so out of my level... I just install everything in any place... And folders all over place + 1 overloaded disk driver  :dance:

PS: This should be a thread called "how far would you go for a path folder"...

[dedndave]

 :bg
environment tables and variables are so simple
it is basic DOS behaviour 101
i don't know why so many people have so many problems with it
i suppose noone wants to master DOS anymore   :P


<-----------------------------

how many clock cycles does it take to multiply 1024 by 33 on an abacus ???