Help with Hello World and NASM on mingw64

[alCoPaUL]

^^ seems to be reversed in windows coz usually a portable win32(x64/x86_32) file is larger than any code that has functions that are dependent on outside libraries.

like you even need to install runtimes if you just wanna make your small program to execute a basic routine.

and yes, in some instances, a code could be smaller if it directly calls the built-in dlls like kernel32.dll or ntdll.dll.

but generally, for hlls, you need to install the language runtimes and if you want your code to run on a computer without the runtime, you have to make your code carry the runtime itself (or something like that)/

[alCoPaUL]

so if you just want to deploy a code that is heavy on C runtime usage on a certain OS (Windows 10 for example), get the appropriate Visual Studio version that builds Windows 10 programs by default. you won't concern or concern less if your code will run on Windows 10 coz it will surely can.

or just call the equivalent native APIs to do the same thing as your runtime dependent code and likely your code will be backwards-compatible.

[fredericopissarra]

You are not understanding what I've said.. "C Runtime" object file is the initialization file linked to EVERY executable (those extra 6 KiB). A lot of initialization is made for a C program to work and, since the "assembly" (in disguise) program uses libc functions, the initialization must be linked to your code...

There is also the MSVCRT.DLL and other files used by your code (take a look with ldd utility). In my exemple, after loaded, the program uses, let's say, 1 KiB of RAM, your C disguised as "assembly" program uses way more...

And I want to deploy a program with NO C runtime dependency and I do not use Visual Studio (argh!). On Windows platform the principle is the same: You can import Win32 API routines, which are independent from C Runtime. This will instruct the linker to load the DLLs using early binding. And will work on EVERY single one of Windows versions, since Windows NT or Windows 95 until Windows 11. No C Runtime needed.

And no... Pure assembly code will always be smaller than mixed asm & C Runtime initialization routines... For the same code, I mean...

[alCoPaUL]

well i can speak for windows coz i delved on windows assembly doing a short personal project.

when you throw an assembly code (win32 or variants) to a disassembler (ida64), it doesn't break down the printf() to pieces, as you were implying.

you can step into the printf() but that's already the code referencing the function and going through it in the msvcrt.dll.

but i might be mistaken, tho. i don't do linux programming or any linux "virtual machine to windows" programming such as ming64 as you were using linux code to explain your side. the OP was using linux assembly so.

[fredericopissarra]

well i can speak for windows coz i delved on windows assembly doing a short personal project.

when you throw an assembly code (win32 or variants) to a disassembler (ida64), it doesn't break down the printf() to pieces, as you were implying.

you can step into the printf() but that's already the code referencing the function and going through it in the msvcrt.dll.

Again.. I never said that... libc function are implemented somewhere, if not statically linked, then in a DLL (or shared object file). In the case of Windows, it is in MSVCRT.DLL or equivalent.

Use your debugger and see what your C disguised as assembly program do from the beginning (not main(), but the image entry point) and you'll see.

but i might be mistaken, tho. i don't do linux programming or any linux "virtual machine to windows" programming such as ming64 as you were using linux code to explain your side. the OP was using linux assembly so.

There's no difference. C Runtime code is still linked to yours, using MinGW, Cygwin or the crappy Visual Studio linker...

My point is: If you have to use C functions from libc, do your program in C. It'll generate better code than yours, probably.

[fredericopissarra]

A simple example:

Code: [Select]

; test.asm
;    nasm -g -fwin64 -o test.o test.asm
;    x86_64-w64-mingw32-gcc -g -o test.exe test.o
;
  bits  64
  default rel

  section .rodata

str:
  db  'Hello',0

  section .text

  extern puts

  ; I hope this works, I don't have Windows here to test.
  global main
  align 4
main:
  xor  eax,eax
  push rax       ; Align RSP and save return value.
  lea   rcx,[str]
  call  puts

  pop rax
  retAfter compiling and linking, using x86_64-w64-mingw32-objdump to get the actual code created:

Code: [Select]

$ x86_64-w64-mingw32-objdump -dM intel test.exeSee the dump file linked.
PS: I've added stack alignment later, there is 3 instructions missing in the listing (but I hope you get the idea)

[debs3759]

As this is a NASM forum, I fail to see the point of posts arguing that C is better.

Given optimised code, and without using outside libraries, asm will always be smaller and/or faster. I know some C compilers will generate better optimisations than the average asm coder, but all being equal, asm is far superior, even if harder to gain competency in

[fredericopissarra]

As this is a NASM forum, I fail to see the point of posts arguing that C is better.

Given optimised code, and without using outside libraries, asm will always be smaller and/or faster. I know some C compilers will generate better optimisations than the average asm coder, but all being equal, asm is far superior, even if harder to gain competency in

Could be smaller (without linking to the entire C Runtime initialization and finalization code), but surely, most of the time won't be faster. As you said, modern C compilers optimizes things an experienced assembly programmer ignores, most of the time. For example: GCC considers minimizing branch prediction and cache misses penalties and improving instruction scheduling -- which is difficult to do by hand. Granted, sometimes the high level language do something redundant (or it seems to be), but, again, most of the time, the generate code is hard to beat, in terms of performance.

Btw, using printf to print a simple string is the slowest way to do it (measure the clock cycles using write syscall and printf!) AND the bloated way to do it as well...

My point: If someone wants to do a program in assembly, do it in assembly without using C functions as crutches. If someone wants to learn assembly, do everything in assembly. At maximum, use a library that don't depend on C runtime to work. Doing so is cheating, not "learning"...

Ahhh... I'm not saying that C cannot be used, is the other way around... In many cases my C routines are faster than the assembly equivalent (and I have 35 years of experience with asm!). In fact, I think if you want to do a complex function in assembly, do it first in C and take a look on what a good compiler creates, THEN you can optimize by hand (if there is some space for it).

[]s
Fred

[Frank Kotler]

These C compilers appear by magic, do they? Somebody must know their assembly language or the compilers wouldn't be any good, no?

What am I missing?

Best,
Frank

[fredericopissarra]

Not a good argument: NASM appeared by magic as well? A C compiler must exist BEFORE assembly, because its entire source code is in C (not ASM). And what about the first assembler? Who made it and in what language?

Another demonstration showing that using printf() is a bad idea:

Code: [Select]

; cycles.asm
;
; Yep, using libc!
;
;    nasm -felf64 -o test.o test.asm
;    ld -o test ./test
;
  bits  64
  default rel

  section .bss

counter:
  resq  1

  section .rodata

hello:
  db `Hello\n`
hello_len equ $ - hello
  db  0

fmt1:
  db  `printf (%llu cycles)\n`,0
fmt2:
  db  `sys_write (%llu cycles)\n`,0

  section .text

  extern printf

  global  main

main:
  sub   rsp,8

  ; Measuring printf call.
  xor   eax,eax
  cpuid                 ; serialize processor.
  rdtsc
  mov   [counter],eax
  mov   [counter+4],edx

  xor   eax,eax
  lea   rdi,[hello]
  call  printf wrt ..plt

  rdtscp
  sub   eax,[counter]
  sbb   edx,[counter+4]

  shl   rdx,32
  mov   esi,eax
  add   rsi,rdx
  xor   eax,eax
  lea   rdi,[fmt1]
  call  printf wrt ..plt

  ; Measuring sys_write.
  xor   eax,eax
  cpuid                 ; serialize processor
  rdtsc
  mov   [counter],eax
  mov   [counter+4],edx

  mov   eax,1
  mov   edi,eax
  lea   rsi,[hello]
  mov   edx,hello_len
  syscall

  rdtscp
  sub   eax,[counter]
  sbb   edx,[counter+4]

  shl   rdx,32
  mov   esi,eax
  add   rsi,rax
  xor   eax,eax
  lea   rdi,[fmt2]
  call  printf wrt ..plt

  add   rsp,8
  ret

Code: [Select]

$ ./cycles
Hello
printf (215525 cycles)
Hello
sys_write (11004 cycles)

[Frank Kotler]

Not a good argument: NASM appeared by magic as well?

Of course not.  Simon Tatham (and Julian Hall) worked hard to  produce it.

A C compiler must exist BEFORE assembly, because its entire source code is in C (not ASM)

True of Nasm, yes. But...

. And what about the first assembler? Who made it and in what language?

Now that's a good question! Surely not C! Bare byte machine code, I would assume...

C, I understand, followed A and B... probably written in an AT&T assembler?

Another demonstration showing that using printf() is a bad idea:

I don't disagree with that. If you want printf to work in Windows, you use a library for Windows. If you want printf to work in Linux, you use a library for Linux. Etc. That's why Nasm is in C. Not for optimized code!

I dunno, Fred. I think we may appear to be arguing about something we actually agree about...

I appreciate your input!

Best,
Frank

[alCoPaUL]

k.

this is the original source made from NASM

~~~~~~~~~
;
; sp4ce.asm
;
; alCoPaUL [GIMO][As][aBrA][NPA][b8]
; 10/6/2021
;
; nasm <dash>f win32 sp4ce.asm
; link sp4ce.obj /subsystem:console /defaultlib:msvcrt.lib /entry:m
;
global m
extern _printf
section .text
m:mov al,10
mov bl,45
z:lea edx,a
mov cx,491
r:cmp byte[edx],bl
je s
jmp u
s:mov byte[edx],al
u:inc edx
dec cx
cmp cx,0
jnz r
push a
push i
call _printf
mov al,10
cmp bl,45
xchg al,bl
je z
push x
push i
call _printf
ret
section .data
x:db 2Ch,32h,37h,68h,2Ch,30h,0
i:db 25h,73h,0
a:db ';-; sp4ce.asm-;-; alCoPaUL [GIMO][As][aBrA][NPA][b8]-; 10/6/2021-;-; nasm <dash>f win32 sp4ce.asm-; link sp4ce.obj /subsystem:console /defaultlib:msvcrt.lib /entry:m-;-global m-extern _printf-section .text-m:mov al,10-mov bl,45-z:lea edx,a-mov cx,491-r:cmp byte[edx],bl-je s-jmp u-s:mov byte[edx],al-u:inc edx-dec cx-cmp cx,0-jnz r-push a-push i-call _printf-mov al,10-cmp bl,45-xchg al,bl-je z-push x-push i-call _printf-ret-section .data-x:db 2Ch,32h,37h,68h,2Ch,30h,0-i:db 25h,73h,0-a:db ',27h,0

~~~~~~~~~~~~~


this is the source generated from IDA..

;
; +-------------------------------------------------------------------------+
; |      This file was generated by The Interactive Disassembler (IDA)      |
; |           Copyright (c) 2019 Hex-Rays, <support@hex-rays.com>           |
; |                      License info: 48-256C-4840-25                      |
; |                     Team-IRA Release [PUBLIC] ,v1.0                     |
; +-------------------------------------------------------------------------+
;
; Input SHA256 : 15AFA3253DA6552C06CF72B15E59D8E7FB98F58D99C0A21F3B6BA529C535165E
; Input MD5    : 9A87262B71B81E2FCD380239CBB560A2
; Input CRC32  : 010A3443

; File Name   : C:\Users\IWAYWarrior\Downloads\Project159_Windows11_NASM_VS2029\e\et\sp4ce.exe
; Format      : Portable executable for 80386 (PE)
; Imagebase   : 400000
; Timestamp   : 616720C4 (Wed Oct 13 18:09:08 2021)
; Section 1. (virtual address 00001000)
; Virtual size                  : 0000004D (     77.)
; Section size in file          : 00000200 (    512.)
; Offset to raw data for section: 00000400
; Flags 60000020: Text Executable Readable
; Alignment     : default

.686p
.mmx
.model flat


; Segment type: Pure code
; Segment permissions: Read/Execute
_text segment para public 'CODE' use32
assume cs:_text
;org 401000h
assume es:nothing, ss:nothing, ds:_data, fs:nothing, gs:nothing



public start
start proc near
mov     al, 0Ah
mov     bl, 2Dh ; '-'

loc_401004:
lea     edx, aSp4ceAsmAlcopa ; ";-; sp4ce.asm-;-; alCoPaUL [GIMO][As][a"...
mov     cx, 1EBh

loc_40100E:
cmp     [edx], bl
jz      short loc_401014
jmp     short loc_401016

loc_401014:
mov     [edx], al

loc_401016:
inc     edx
dec     cx
cmp     cx, 0
jnz     short loc_40100E
push    offset aSp4ceAsmAlcopa ; ";-; sp4ce.asm-;-; alCoPaUL [GIMO][As][a"...
push    offset Format   ; "%s"
call    printf
mov     al, 0Ah
cmp     bl, 2Dh ; '-'
xchg    al, bl
jz      short loc_401004
push    offset a27h0    ; ",27h,0"
push    offset Format   ; "%s"
call    printf
retn
start endp ; sp-analysis failed

; [00000006 BYTES: COLLAPSED FUNCTION printf. PRESS CTRL-NUMPAD+ TO EXPAND]
align 200h
dd 380h dup(?)
_text ends

; Section 2. (virtual address 00002000)
; Virtual size                  : 00000160 (    352.)
; Section size in file          : 00000200 (    512.)
; Offset to raw data for section: 00000600
; Flags 40000040: Data Readable
; Alignment     : default
;
; Imports from MSVCR100.dll
;

; Segment type: Externs
; _idata
; int printf(const char *const Format, ...)
extrn __imp_printf:dword


; Debug Directory entries

; Segment type: Pure data
; Segment permissions: Read
_rdata segment para public 'DATA' use32
assume cs:_rdata
;org 402008h
dd 0                    ; Characteristics
dd 616720C4h            ; TimeDateStamp: Wed Oct 13 18:09:08 2021
dw 0                    ; MajorVersion
dw 0                    ; MinorVersion
dd 0Dh                  ; Type: IMAGE_DEBUG_TYPE_POGO
dd 0DCh                 ; SizeOfData
dd rva unk_40203C       ; AddressOfRawData
dd 63Ch                 ; PointerToRawData
db  18h
db    0
db    0
db    0
db    0
db  80h ; €
db    0
db  80h ; €
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
db    0
; Debug information (IMAGE_DEBUG_TYPE_POGO)
unk_40203C db    0
db    0
db    0
db    0
db    0
db  10h
db    0
db    0
db  47h ; G
db    0
db    0
db    0
db  2Eh ; .
db  74h ; t
db  65h ; e
db  78h ; x
db  74h ; t
db    0
db    0
db    0
db  47h ; G
db  10h
db    0
db    0
db    6
db    0
db    0
db    0
db  2Eh ; .
db  74h ; t
db  65h ; e
db  78h ; x
db  74h ; t
db  24h ; $
db  6Dh ; m
db  6Eh ; n
db    0
db    0
db    0
db    0
db    0
db  20h
db    0
db    0
db    8
db    0
db    0
db    0
db  2Eh ; .
db  69h ; i
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  35h ; 5
db    0
db    0
db    0
db    0
db    8
db  20h
db    0
db    0
db  1Ch
db    0
db    0
db    0
db  2Eh ; .
db  72h ; r
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db    0
db    0
db  24h ; $
db  20h
db    0
db    0
db  18h
db    0
db    0
db    0
db  2Eh ; .
db  72h ; r
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  76h ; v
db  6Fh ; o
db  6Ch ; l
db  74h ; t
db  6Dh ; m
db  64h ; d
db    0
db    0
db    0
db  3Ch ; <
db  20h
db    0
db    0
db 0DCh ; Ü
db    0
db    0
db    0
db  2Eh ; .
db  72h ; r
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  7Ah ; z
db  7Ah ; z
db  7Ah ; z
db  64h ; d
db  62h ; b
db  67h ; g
db    0
db    0
db    0
db  18h
db  21h ; !
db    0
db    0
db  14h
db    0
db    0
db    0
db  2Eh ; .
db  69h ; i
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  32h ; 2
db    0
db    0
db    0
db    0
db  2Ch ; ,
db  21h ; !
db    0
db    0
db  14h
db    0
db    0
db    0
db  2Eh ; .
db  69h ; i
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  33h ; 3
db    0
db    0
db    0
db    0
db  40h ; @
db  21h ; !
db    0
db    0
db    8
db    0
db    0
db    0
db  2Eh ; .
db  69h ; i
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  34h ; 4
db    0
db    0
db    0
db    0
db  48h ; H
db  21h ; !
db    0
db    0
db  18h
db    0
db    0
db    0
db  2Eh ; .
db  69h ; i
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db  24h ; $
db  36h ; 6
db    0
db    0
db    0
db    0
db    0
db  30h ; 0
db    0
db    0
db 0F7h ; ÷
db    1
db    0
db    0
db  2Eh ; .
db  64h ; d
db  61h ; a
db  74h ; t
db  61h ; a
db    0
db    0
db    0
__IMPORT_DESCRIPTOR_MSVCR100 dd rva off_402140 ; Import Name Table
dd 0                    ; Time stamp
dd 0                    ; Forwarder Chain
dd rva aMsvcr100Dll     ; DLL Name
dd rva __imp_printf     ; Import Address Table
align 20h
;
; Import names for MSVCR100.dll
;
off_402140 dd rva word_402148
dd 0
word_402148 dw 5D7h
db 'printf',0
align 2
aMsvcr100Dll db 'MSVCR100.dll',0
align 1000h
_rdata ends

; Section 3. (virtual address 00003000)
; Virtual size                  : 000001F7 (    503.)
; Section size in file          : 00000200 (    512.)
; Offset to raw data for section: 00000800
; Flags C0000040: Data Readable Writable
; Alignment     : default

; Segment type: Pure data
; Segment permissions: Read/Write
_data segment para public 'DATA' use32
assume cs:_data
;org 403000h
a27h0 db ',27h,0',0
; char Format[]
Format db '%s',0
aSp4ceAsmAlcopa db ';-; sp4ce.asm-;-; alCoPaUL [GIMO][A'
db 's][aBrA][NPA][b8]-; 10/6/2021-;-; n'
db 'asm <dash>f win32 sp4ce.asm-; link '
db 'sp4ce.obj /subsystem:console /defau'
db 'ltlib:msvcrt.lib /entry:m-;-global '
db 'm-extern _printf-section .text-m:mo'
db 'v al,10-mov bl,45-z:lea edx,a-mov c'
db 'x,491-r:cmp byte[edx],bl-je s-jmp u'
db '-s:mov byte[edx],al-u:inc edx-dec c'
db 'x-cmp cx,0-jnz r-push a-push i-call'
db ' _printf-mov al,10-cmp bl,45-xchg a'
db 'l,bl-je z-push x-push i-call _print'
db 'f-ret-section .data-x:db 2Ch,32h,37'
db 'h,68h,2Ch,30h,0-i:db 25h,73h,0-a:db'
db ' ',27h,0
align 1000h
_data ends


end start

~~~~~~

so printf() is not broken down to pieces as you imply BUT is listed "by function" for EXTERNAL use,

as i saw, you converted the .asm object file to linux executable using GCC and compared it to the generated linux executable with different routines (with SYSCALL) to display texts using ld. you can link your print() assembled file using ld.exe WITH the appropriate C runtime library with your linux object file. try that and compare again,.

edit: the actual runtime for executing the code is MSVCR100.dll and you need to link the .obj file to the generic .dll file for the appropriate runtime file version (e.g. msvcrt.dll for Visual Studio 2010 C/C++).
edit1: grammar, etc.

[alCoPaUL]

and to add.

you saw that the source that i posted with printf() is not made with #include <whatever> and curly braces. it uses opcodes and numbers.

and you sound that you're complaining for the fact that printf() did some epic stuff so you wanna discredit it by comparing an assembled code with printf() that you linked with GCC to an assembled code with SYSCALL and linking it with ld.exe.

as i said, try linking your printf() assembled file with ld.exe coz you can do that.

like yo, you've programmed assembly for 35 years and suddenly an assembly code using printf() is not assembly language??

like wtf lelz men.

[fredericopissarra]

Let's play a game then... Let's make a small program. You do your way, I do mine...
Wins who made them SMALLER and running FASTER.
And for Windows (argh!)...

I'll wait for a proposal of what to do...

BTW: That code above doesn't work (pushing arguments to _printf and not correcting ESP after the call will cause a seg fault). There are other errors.

I'll show what you're doing wrong with that IDA listing later (When I got my hands on WINDOWS and VS - I don't have them at home).

[fredericopissarra]

BWAHAHAHAHAHAHAHAHA... Your code isn't compiling! There is no _printf on MSVCRT!

Code: [Select]

C:\Windows\System32>dumpbin /exports msvcr100.dll | findstr _printf
        640  27F 000656F1 _get_printf_count_output
        981  3D4 0006564C _printf_l
        982  3D5 000656AF _printf_p
        983  3D6 00065696 _printf_p_l
        984  3D7 00065665 _printf_s_l
       1031  406 000656C7 _set_printf_count_outputSame for msvcrt.dll

Code: [Select]

C:\Work\tmp> link test.obj /defaultlib:msvcrt.lib /subsystem:console
link test.obj /defaultlib:msvcrt.lib /entry:start /subsystem:console /entry:start
Microsoft (R) Incremental Linker Version 14.29.30147.0
Copyright (C) Microsoft Corporation.  All rights reserved.

test.obj : error LNK2001: símbolo externo não resolvido _printf
test.exe : fatal error LNK1120: 1 externo não resolvidosYep... LIB and INCLUDE environment vars are correct.