Creating my First Program

[soulvomit]

Unfortunately it makes perfect sense and also makes me cry. That's a real bummer. I'll be doing more reading as the day goes by. Thanks for everything, man. I really appreciate it.

Hi, I'll get back to you later on some of your other concerns.

Why does this make you sad? It means your program is working fine What did you expect your program to do?

[WannaLearn]

http://stackoverflow.com/questions/18296088/check-the-platform-of-the-installed-mingw-32bit-or-64-bit
According to this thread which says that you check the MINGW version by using the "gcc --version" command, The MINGW version I'm using is:
gcc (rubenv-4.7.2-release)
I just wanted to note that I download MINGW 2 days ago and followed the direction in the Guide linked below which reads: "Click on this mingw-get-setup.exe link, to download the latest available version of mingw-get-setup.exe"
http://www.mingw.org/wiki/getting_started

Just wanted to get back to you with this one, I'll get back to the rest later on. Your version of MINGW is distinctly 32-bit. To do any 64-bit programming (-fwin64) in Nasm, you'll need the 64-bit version of MINGW (the one I linked earlier).

However, if you are as new as you stated, you should really do what the mingw getting_started tutorial tells you. Stick with 32-bit assembly (-fwin32). What you learn in the 32-bit space (we usually call it x86) will be easily translatable, when you do decide to take the jump over to 64-bit (called x86-64, or simply x64).     

EDIT: From a Windows developers standpoint MINGW and Cygwin offer a version of the GNU toolchain (includes programs like gdb - gnu debugger, ld - gnu linker and gcc - gnu compiler), which is normally only accessible to Linux users. Basically it ports the Linux GNU toolchain to Windows. Personally I need the whole GNU toolchain, but it is NOT needed to start Nasm programming.
If you want a lightweight development environment, without all the bells and whistles, you can simply get; Nasm for Windows, GoLink, Notepad++ and use the windows command prompt (cmd) to assemble and link.

Alrighty, I've been tinkering around for the last few days and finally received output using 3 different "Hello  World" asm scripts and figured out how to use ld to call the appropriate dlls.

GoLink is AMAZING!!!
The safe GoLink commands I've been using to link have been:

Code: [Select]

golink /console /entry  _*   *.obj  kernel32.dll  user32.dll  MSVCRT.dll

En route to finding the ld equivalent I've been using this:

Code: [Select]

ld main.obj -e* -lkernel32 --enable-stdcall-fixup %SYSTEMROOT%\system32\kernel32.dll
Predictably when you "echo %systemroot% you find the appropriate path to your dll files (obviously). I'm just including this for people who read the thread in the future)


On that note a few bits of confusion I have:
- Why is it that with basic scripts it would seem that "nasm -f win32 *.obj" is more reliable when running an exe after linking than "nasm -f win64 *.obj" on my 64-bit machine. Why does "nasm -f win32" work in the first place?  guess the linker serves as kind of a handler for this or is it that the Windows machine actually makes its own internalized exceptions.
- [/Gotta run] I'll type the other questions when I return

Unfortunately it makes perfect sense and also makes me cry. That's a real bummer. I'll be doing more reading as the day goes by. Thanks for everything, man. I really appreciate it.

Hi, I'll get back to you later on some of your other concerns.

Why does this make you sad? It means your program is working fine What did you expect your program to do?

I was upset because my program was "crashing" unbeknownst to me. Counterintuitive, haha

[Frank Kotler]

If your program is returning the errorlevel you specify, it isn't crashing. If it were crashing, your OS would let you know. (used to be a "gpf" - I think they call it "access violation" now) It is conventional to return an errorlevel of zero if all went well. It may be better to use the C library "exit()" or the API "ExitProcess", but just "ret" should work. This is not true in Linux, where the "_start" label is not "call"ed but "jmp"ed to. There is no return address on the stack, so "ret" won't work!

Now that you've got "hello world" working, try asking your name and "hello uhClem". Then you've got IO and you're on your way!

Best,
Frank

[soulvomit]

En route to finding the ld equivalent I've been using this:

Code: [Select]

ld main.obj -e* -lkernel32 --enable-stdcall-fixup %SYSTEMROOT%\system32\kernel32.dll

Good job on this

[soulvomit]

- Why is it that with basic scripts it would seem that "nasm -f win32 *.obj" is more reliable when running an exe after linking than "nasm -f win64 *.obj" on my 64-bit machine. Why does "nasm -f win32" work in the first place?  guess the linker serves as kind of a handler for this or is it that the Windows machine actually makes its own internalized exceptions.

Making 64-bit programs is not inherently less reliable then making 32-bit programs. The reason it is less reliable for you, is still that you use a 32-bit version of mingw. That toolchain is meant to produce 32-bit programs. If you link with GoLink, there shouldn't be any difference in the reliability of 32-bit and 64-bit.

Like I said earlier; a 64-bit processor supports the x86-64 instruction set. This means that your 64-bit processor is backwards compatible, with any 32-bit (x86) code.

[WannaLearn]

Let me apologize again for the tardiness of my reply. Please feel free to delay any responses because I've been swamped with work lately (School + Learning regex to create parsers for work [got some good resources for it but videos are definitely the best]).

If your program is returning the errorlevel you specify, it isn't crashing. If it were crashing, your OS would let you know. (used to be a "gpf" - I think they call it "access violation" now) It is conventional to return an errorlevel of zero if all went well. It may be better to use the C library "exit()" or the API "ExitProcess", but just "ret" should work. This is not true in Linux, where the "_start" label is not "call"ed but "jmp"ed to. There is no return address on the stack, so "ret" won't work!
Now that you've got "hello world" working, try asking your name and "hello uhClem". Then you've got IO and you're on your way!

Thanks for the info Frank. I wish I'd have had more time to work on NASM over the past week. I'm going to try to get back into it after i meet my deadlines.

En route to finding the ld equivalent I've been using this:

Code: [Select]

ld main.obj -e* -lkernel32 --enable-stdcall-fixup %SYSTEMROOT%\system32\kernel32.dll

Good job on this

Reading. Always have to love it, haha

- Why is it that with basic scripts it would seem that "nasm -f win32 *.obj" is more reliable when running an exe after linking than "nasm -f win64 *.obj" on my 64-bit machine. Why does "nasm -f win32" work in the first place?  guess the linker serves as kind of a handler for this or is it that the Windows machine actually makes its own internalized exceptions.

Making 64-bit programs is not inherently less reliable then making 32-bit programs. The reason it is less reliable for you, is still that you use a 32-bit version of mingw. That toolchain is meant to produce 32-bit programs. If you link with GoLink, there shouldn't be any difference in the reliability of 32-bit and 64-bit.
Like I said earlier; a 64-bit processor supports the x86-64 instruction set. This means that your 64-bit processor is backwards compatible, with any 32-bit (x86) code.

Wow. I didn't fully process the "x86-64" backward compatibility ability before. Is there a specific notation for systems that are not backward compatible like "x64" only or something akin to that?

[soulvomit]

Wow. I didn't fully process the "x86-64" backward compatibility ability before. Is there a specific notation for systems that are not backward compatible like "x64" only or something akin to that?

For now x86-64 = x64. There is no difference. All newer AMD and Intel processors support the instruction set, although AMD labels it as AMD64. There might be some chip vendors (maybe ARM or VIA), who make CPUs that are strictly 64-bit, I'm not sure. But they might also use a different instruction set altogether (ARM certainly do). In the personal computing CPU vendor space; AMD64 = x86-64 = x64.

https://en.wikipedia.org/wiki/X86-64

Even the newest/unreleased CPUs from AMD and Intel, such as Zen and Kaby Lake, support the x86-64 instruction set:

https://en.wikipedia.org/wiki/Zen_(microarchitecture)
https://en.wikipedia.org/wiki/Kaby_Lake