LINK : error LNK2001: unresolved external symbol _mainCRTStartup

[cyrus]

I'm really liking this masm32 a lot. Can't believe I haven't been using it. I've been looking at the examples. A great solid piece of software put together and this is such a great forum as well. Thank you all.

Just ffs I guess, how do I find out what the name mangling is for other functions? I tried looking it up and couldn't find it. I'm looking for FindFirstFileA and FindNextFileA. I tried adding the @4 but still having trouble linking with that.

Update: I now understand the mangling thing. When I disassemble my c++ with g++ -S -fverbose, I am able to see all those functions. These two are @8

[cyrus]

I noted that you have used 10 in your example as being a new line. On windows a new line is 13,10, on linux that's 10. End os string in both are 0.
The C calling convention is equal in windows32 and linux32, so, if you try jwasm/uasm/asmc you're able to create  an executable in linux too. The main problem will be function names that exist in both O.S.
This is a snippet to try.

Code Select Expand

;ML.EXE /c /coff /Cp /nologo /I"C:\Masm32\Include" "printf.asm"
;LINK.EXE /SUBSYSTEM:CONSOLE /RELEASE /VERSION:4.0 /LIBPATH:"C:\Masm32\Lib" /OUT:"printf.exe" "printf.obj"

.386
option casemap:none
.model flat,stdcall

WIN32 EQU 1 ;define WIN32

IFDEF LIN32
NL EQU 10
ENDIF

IFDEF WIN32

include msvcrt.inc
include kernel32.inc

includelib msvcrt.lib
includelib kernel32.lib

printf textequ <crt_printf>
exit textequ <crt_exit>
NL EQU 13,10
ENDIF

.data
fmt_msg db "have %d good days",NL,0

.code
main proc

invoke printf,addr fmt_msg,10
invoke exit,0

main endp

end main


Thanks for that piece of code. Yeah it's definitely better to use the IF directive, saves a lot of headache.
As for the newline, yes you are right, I am using 10,0 but I know about 13,10,0. In fact I do use that most of the time but for this particular piece of code and most for testing, I don't add 13, because I might be comparing output say from a recursive function in windows to a listing from linux. I use linux as my main OS and only use windows as a VM. So I use the cmp command in linux through a share thats mapped in windows.

[TimoVJL]

I'm really liking this masm32 a lot. Can't believe I haven't been using it. I've been looking at the examples. A great solid piece of software put together and this is such a great forum as well. Thank you all.

Just ffs I guess, how do I find out what the name mangling is for other functions? I tried looking it up and couldn't find it. I'm looking for FindFirstFileA and FindNextFileA. I tried adding the @4 but still having trouble linking with that.

Code Select Expand

FindFirstFileA PROTO STDCALL :DWORD,:DWORD
IFNDEF __UNICODE__
  FindFirstFile equ <FindFirstFileA>
ENDIF
so two params 2 * 4 = 8

Code Select Expand

FindFirstFileA@8

Code Select Expand

FindNextFileA PROTO STDCALL :DWORD,:DWORD
IFNDEF __UNICODE__
  FindNextFile equ <FindNextFileA>
ENDIF

Code Select Expand

FindNextFileA@8

[zedd151]

I'm really liking this masm32 a lot. Can't believe I haven't been using it. I've been looking at the examples. A great solid piece of software ...

Absolutely. With the problems that you initially described, I pretty much knew that you didn't have it (Masm32 SDK) at that point.
Hutch put together the Masm32 SDK specifically to make learning 32 bit assembly for Windows as easy as can be.  No need to worry about name mangling in most instances.
Using batch files (makeit.bat, for example) makes it easy to produce your executable without fumbling with VS settings too (or manually via the command line). VS is generally overkill for creating assembly programs, imho. Unless of course, there is a specific need to use it.

[Vortex]

Hi cyrus,

You can also use Agner Fog's objconv to disassemble object files to study mangled symbols.

[NoCforMe]

I tried looking it up and couldn't find it. I'm looking for FindFirstFileA and FindNextFileA. I tried adding the @4 but still having trouble linking with that.

Couple things:

• You usually don't need to specify the -A or -W flavor of those functions that come in both varieties (A is for "ASCII" and W is for "wide", meaning Unicode). For folks like me who rarely use Unicode, just code FindFirstFile and it'll default to the A version. If you ever do need the Unicode flavors, you can specify the W version.
• You should never, ever have to resort to adding that stupid @<# bytes of parameters nonsense if you just use the MASM32 include files. All that behind-the-scenes nonsense becomes invisible to you, and you can just have fun programming instead of endlessly scratching your head over those weird constructs ...

[sinsi]

All that behind-the-scenes nonsense becomes invisible to you, and you can just have fun programming instead of endlessly scratching your head over those weird constructs ...

Some of us are masochistic enough to like the bare bones approach for smaller programs of course.That's why 64-bit programming is ... exciting.

[NoCforMe]

Some of us are masochistic enough to like the bare bones approach for smaller programs of course.That's why 64-bit programming is ... exciting.

Well, all in good time. First we need to soften up this n00b, lure him into thinking programming is fun before having him ride over the waterfall in a barrel ..

Besides, you know me, sinsi. I don't go in for any of that macro nonsense either ...

It's like that old saying: reality is just a crutch for those who can't handle drugs.

[Vortex]

ChatGPT's explanations on name mangling :

Name mangling is a technique used by compilers to handle function overloading and to ensure that functions with the same name but different parameters are uniquely identifiable. It involves encoding additional information into the names of functions to differentiate them.

In the context of Windows programming, particularly when discussing 64-bit Windows and the C++ programming language, there are a few key reasons why name mangling is not a major issue:

1. **Calling Conventions and ABI**: On 64-bit Windows (often using the Microsoft x64 calling convention), the application binary interface (ABI) specifies how functions are called and how parameters are passed. This ABI allows for clear differentiation of functions based on their signatures without relying on name mangling. The calling convention and ABI details ensure that function signatures are unique enough to avoid conflicts.

2. **Name Mangling in C++**: While name mangling is indeed used in C++ to handle function overloading and to ensure unique function names, the 64-bit Windows environment does not change the fundamental need for name mangling. However, the mangling schemes used might differ between compilers and platforms. On 64-bit Windows, Microsoft's compiler uses a specific mangling scheme, but it operates under the same principles of encoding additional function signature information into the name.

3. **Linkage and Compatibility**: The way name mangling is handled in 64-bit Windows is compatible with the existing standards and practices of C++ compilation and linking. The mangling process itself remains relevant for function overloading and linking, but the specifics of how it is implemented may vary. The general principles of name mangling are still present, but the linkage and ABI conventions of the 64-bit Windows environment help to manage the function signatures effectively.

4. **Modern Development Practices**: Modern C++ development practices and tools often provide additional layers of abstraction and linkage management that can mitigate the visibility of name mangling issues. Tools like `extern "C"` for C linkage or the use of namespace scopes can help manage and reduce potential conflicts.

In summary, name mangling is still a relevant concept in 64-bit Windows programming, particularly for C++ code. However, the 64-bit ABI and calling conventions help manage and mitigate the complexity associated with it, making it less of a prominent issue in terms of programming and linking.

[zedd151]

@cyrus

Code Select Expand

include \masm32\include\masm32rt.inc

.data

hello db "hello", 13, 10, 0

.code

main proc
    invoke StdOut, addr hello
    inkey
    invoke ExitProcess, 0
main endp

end main

batch file to build it

Code Select Expand

@echo off

set appname=test3
if exist %appname%.obj del %appname%.obj
if exist %appname%.exe del %appname%.exe

\masm32\bin\ml.exe /c /coff /nologo %appname%.asm
\masm32\bin\link.exe /SUBSYSTEM:CONSOLE /ENTRY:main /nologo %appname%.obj

dir %appname%.*

pause