Hi there,
I'm using MASM 6.11b.
I changed the directive at the top of shell.asm to 'include stdlib6.a' and tried to compile like so...
and I got the following errors....
stdlib6.a(924) : error A2085 : instruction or register not accepted in current CPU mode
stdlib6.a(926) : fatal error A1008 : unmatched macro nesting
I have yet to write any code yet! How can I get this to compile?
Thanks,
S
I'm using MASM 6.11b.
I changed the directive at the top of shell.asm to 'include stdlib6.a' and tried to compile like so...
ml shell.asm
and I got the following errors....
stdlib6.a(924) : error A2085 : instruction or register not accepted in current CPU mode
stdlib6.a(926) : fatal error A1008 : unmatched macro nesting
I have yet to write any code yet! How can I get this to compile?
Thanks,
S
Hi there,
I'm using MASM 6.11b.
I changed the directive at the top of shell.asm to 'include stdlib6.a' and tried to compile like so...
ml shell.asm
and I got the following errors....
stdlib6.a(924) : error A2085 : instruction or register not accepted in current CPU mode
stdlib6.a(926) : fatal error A1008 : unmatched macro nesting
I have yet to write any code yet! How can I get this to compile?
Thanks,
S
You're using v2.0 of the library, which is severely broken.
The first error sounds like you're missing a ".486" directive, or such.
However, keep in mind that I abandoned the UCR stdlib v2.0 because
of bugs in MASM v6.11 (that's what led to the creation of HLA).
The last time I compiled v2.0 (successfully) was with MASM v6.11a.
Things were broken so bad in MASM v6.11d (the next version I tried)
that I just gave up. The UCR stdlib v2.0 was really pushing MASM to
the limits and I couldn't handle the fact that minor version changes
(in MASM) were creating so many problems for me.
If you must run under DOS, consider using the HLA stdlib v1.x system.
Better yet, switch to Windows and use the HLA stdlib for MASM users
(or even better still, use HLA!).
Cheers,
Randy Hyde
OK, thanks for that.
So do assembly language products normally flout backwards compatibility?
Are ASM people supposed to be able to take the pain?
So do assembly language products normally flout backwards compatibility?
Are ASM people supposed to be able to take the pain?
OK, thanks for that.
So do assembly language products normally flout backwards compatibility?
Are ASM people supposed to be able to take the pain?
Well, to be honest I was pulling some tricks with MASM that weren't *exactly* documented. That is, I just tried a bunch of things until I got something to work. The fact that it broke when they switched versions probably meant that I was taking advantage of defects in the code with my macros.
Personally, I could have dealt with this, but I was developing the UCR stdlib v2.0 for beginning students. And the errors I was getting would have totally confused them. That's why I abandoned MASM at that point. I probably could have come up with a working solution that was okay whenever the macros were used properly, but they weren't robust enough to handle incorrect usage (i.e., the kind of stuff that students produce). Even when the macros were working correctly, if you had a syntax error, the messages MASM produced were, well, interesting...
Cheers,
Randy Hyde