the code in the above post can be linked with: nasm -f win32 hellow.asm \watcom\binnt\link hellow.obj the code in this post can be linked with: nasm -f win32 hello.asm \dev-cpp\bin\ld -l kernel32 -L %windir%\system32 hello.obj -o hello.exe i had to use -o. i had previously seen ld terminate without any error messages, during my experimentation the other day, and had assumed that it had failed silently due to some bug. i guess it's just too stupid to know that the output should be .exe. The other thing that looked like a bug is that when it can't find a library, it says "-lkernel32" with no space after -l. It seems cumbersome having to tell the linker to look in the system32 folder every time you want to link a file. It seems that it should look there automatically, unless you specify otherwise. Where else would kernel32.dll be? According to: http://sourceware.org/binutils/docs/ld/WIN32.html the DLLs export aliases without stdcall mangling. Indeed, I had to remove the @nn suffixes. Why then, did I have to add them before, when I was using gcc instead of ld? Was it linking to "\Dev-Cpp\lib\libkernel32.a" instead of the actual .dll? I tried linking to libkernel32.a the other day, but wasn't able to, probably because I was omitting the -o. The watcom linked executable is almost 2K smaller. I assume it's linking to "\WATCOM\lib386\nt\kernel32.lib" instead of the actual .dll? Regards, Michael ------------------- cpu 586 extern _GetStdHandle extern _WriteConsoleA extern _ExitProcess global _mainCRTStartup section .text _mainCRTStartup: push dword 0xfffffff5 call _GetStdHandle mov [_stdout],eax push dword 0x0 push dword _trash push dword _msgend-_msg push dword _msg push dword [_stdout] call _WriteConsoleA push dword 0x0 call _ExitProcess section .data _msg: db "Hello, world, using ld." _msgend: section .bss _stdout: resd 0x1 _trash: resd 0x1
|
