Frank Kotler wrote:
> Thanks for your contribution! Sorry for the delay in responding (I'm
> distracted lately). I don't know what to do with this *but* send it on
> to the development list for comments. This sometimes amounts to
> ">/dev/nul", but not always :)
Hi to All,
A big 'thank you' to Frank and to all you folks for taking a look at this.
> As you know, Nasm is determinedly ignorant of what OS it's running on.
> This, of course, "breaks" that. In reality, Nasm is mostly running on
> MS's cartoon OS. Perhaps it's time for Nasm to acknowledge this fact...
> I don't know...
I think it is possible to preserve this to the extent that it now exists
with a variation on what I proposed earlier (one that I suggest below).
>>I do a lot of work using NASM with Microsoft VC++ In
>>particular I offer AES, GMP, NTL and MPFR builds that make
>>use of NASM.
>>Its a great product but I have one problem for which a small
>>change would be a BIG help in integrating NASM with VC++.
>>It turns out that the 'current directory' and the 'input
>>file directory' in VC++ can be completely different. And
>>when this happens with NASM, any include files that are in
>>the same directory as the NASM source file won't be found.
>>This is a real nuisance and one that greatly complicates the
>>use of NASM with VC++ (all the fixes are very messy).
>>But a small change in nasm.c - by adding the following at
>>the end of parse_cmdline:
>> if( (p = strrchr(inname, '\')) && (p > inname)
>> || (p = strrchr(inname, '/')) && (p > inname) )
>> char *q = nasm_malloc(p - inname + 2);
>> strncpy(q, inname, p - inname + 1);
>> q[p - inname + 1] = '\0';
> This won't compile for me - "unterminated character constant". I changed
> the " '\' " to " '\\' ", and it worked. I *think* this still does what
> you intend(???).
Yes, this was an error in my cut and paste since the above does not
compile for me either - sorry about that :-(
> Anyone got any comments on this? (or any other of the many pending
> issues? virtual sections??? allowing a size on "lea"? ...) I *really*
> hate to see Nasm start down the OS-specific path. I suppose we've
> already started, with the alternate formatting of the error messages...
> perhaps that was a mistake. I wonder how many people actually *use*
I do! I used to have to distribute a specially compiled version of NASM
for use with VC++ but the adoption of this switch has made my life a lot
easier since I can now refer people to the normally distributed version.
I get quite a lot of interest in my GMP, NTL and AES assembler code that
uses NASM with VC++ so this switch has been a big help for me. I suspect
this is true for a lot of VC++ users since it makes NASM very much
easier to use in the VC++ IDE.
> The other OS-specific "enhancement" that someone slipped in - the
> "backslash()" function - had to be removed, as it broke documented
Assuming that nobody wants to remove the -Xvc switch, the following in
place of what I suggested earlier will do what I seek without adding any
functionality when the VC switch is not invoked:
if(report_error == report_error_vc)
char *p = strrchr(inname, '\\'), *q = strrchr(inname, '/');
if(p || q)
int len = ((p && q) ? (p > q ? p : q) : (p ? p : q)) - inname + 1;
q = nasm_malloc(len + 1);
strncpy(q, inname, len);
q[len] = '\0';
Hence this won't impact on non-VC users at all but will add a feature
that will be a great help for VC users of NASM. And it is no more OS
dependent that NASM is already :-)
> Nasm provides "good" methods for manipulating the include search path -
> I find the environment variable works most conveniently for most things.
> Maybe the command line would be more appropriate here - you're
> specifying the path to "infile", anyway... But, in fact, our users have
> a lot of trouble in this area. Perhaps the MS tools don't handle it
> well, perhaps it needs to be better documented, perhaps Nasm needs to
> change its philosophy...
I have tried all of these and they are not really satisfactory with
Windows because of space characters in path names, which NASM interprets
as the end of command line arguments. I can get round this with the
source file path by enclosing it in double quote characters but this
does not work for the -I switch so NASM fails with a 'multiple input
A simple technique that ensures that NASM will always look in the source
file directory for possible include files makes sense whether VC++ is
being used or not. But I would certainly be most grateful even if this
is limited to VC++ as suggested above.
This will help a lot of VC++ users and will be even more useful early
next year because the new version of VC++ has facilities for full
external tool integration and this will mean that NASM can then become a
fully integrated assembler for VC++.