Recent Posts

Pages: [1] 2 3 ... 10
1
The Campus / Re: Masm x86 Assembly Language
« Last post by hutch-- on Today at 11:22:38 AM »
You need to tell us a bit more about what you are using, I gather it is the 32 bit version of MASM and from the procedures you are calling, it looks like Irvine library modules.
2
MASM64 SDK / MOVED: Masm x86 Assembly Language
« Last post by hutch-- on Today at 11:20:44 AM »
3
The Campus / Masm x86 Assembly Language
« Last post by navidmudassir17 on Today at 10:30:04 AM »
Using the following form

.data

.code

coding
call Create RandomArray
call PrintArray
call PrintReverseArray
call CountArray
call PrintCount
call PrintCountGraph
more coding

main endp
All methods
•   Write the program to create 100random numbers from 20 to 30 and print them in an array called TestArray
•   Print the array out with all numbers
•   The print the numbers in reverse
•   Print the array out us1ng ptr
•   The count how many of each number there was.
•   Print the count out as numbers
•   Print the counts out a a bar graph
Ex 20 ****
21 ******
25 ****

•   The graph must use a drawline method

i need help in assembly language with MASM
I tried everything but my program does not work
4
The Campus / MOVED: Unknown relocation type (1) error
« Last post by hutch-- on Today at 09:18:15 AM »
6
Mark,

While the 64 bit version of MASM looks much like the 32 bit version of MASM32, they are structurally very different and the 64 bit version had to be written from scratch and that meant includes, libraries and macros. When a dedicated system provided runtime library like MSVCRT is used, it has many hundreds of function names in it, some of which cannot be used due to being the same as MASM reserve words and then you have a multitude of later variations on MSVCRT which have overlaps in function names so the cleanest solution was to prefix the function names so that you could use any of the versions of MSVC****.LIB without linker errors from trying to use the same name for different runtime DLLs.

The 64 bit project does NOT attempt to be backwards compatible with the 32 bit version as it will not be compromised with the assumptions of 16 and 32 bit code, at a coding level it looks similar but behind that, it is very different by necessity due to OS design differences.
7
hello qWord and Vortex,

I see what Vortex means and I agree with him that vc_ is visibly more accurate. 

It remains unclear to me why not just leave the original textequ macro so it matches others found in import libraries like kernel32.lib  I understand the point about name conflicts in the abstract, but are they any more prevalent or likely to occur than conflicts over printf and other msvcrt functions simply because printf gets prepended with vc_ ?  I guess you think so.

Anyway, thanks both of you for helping me with this.  It's bothered me for quite some time and I was too lazy to investigate.  And perhaps a bit too shy.

Mark
8
I think vc_ looks more descriptive as there are two main versions of C run-time DLLs :

Code: [Select]
msvcrt.dll
crtdll.dll

Naturally, one can find more DLLs with each release of Visual Studio.
9
There are two set of includes: one for 32 bit code (\masm32\include\) and one for 64 bit code (\masm32\include64\). I cannot tell you why hutch changed the prefix from crt_ to vc_ for 64 bit, but as said, the purpose of these prefixes is just to avoid name conflicts.

regards
10
Hello again, qWord,

Thanks for your explanation.  I think I see what happened.  I have been reading the coff/pe specs for a few days now and had previously looked at the .idata section, so I was able to follow your tutorial.

A question out of curiosity:  what happened to the crt prefix for msvcrt functions?  I didn't find it when I inspected the Include64 msvcrt.inc file?  Perhaps it was deprecated when 64 bit came along?

Regards,
Mark
Pages: [1] 2 3 ... 10