Why GCC executable are so bloated?

7kb of code for hello world?

>>39
Not bad, filealign + merge did the trick. Setting the entrypoint directly removed some 100+ bytes of overhead(the entrypoint function is always statically linked, as it can sometimes contain application specific information. Any functions the entrypoint used would either be linked dynamically or statically, depending on the options), however setting the entrypoint like that won't generate a portable Win32 executable (it may fail when used in some (future) Win32's or when using some executable packers/protections). The reason for this is because your code will get translated to something like(I just posted what it does on my box):

.00401016: 55                             push        ebp
.00401017: 8BEC                           mov         ebp,esp
.00401019: 6808104000                     push        000401008 ;'Hello world!' --↑1
.0040101E: FF1500104000                   call        printf
.00401024: 59                             pop         ecx
.00401025: 33C0                           xor         eax,eax
.00401027: 5D                             pop         ebp
.00401028: C3                             retn
.00401029: CC                             int         3
.0040102A: CC                             int         3
.0040102B: CC                             int         3
[code]
So you have the function prologue/epilogue (can be eliminated by increasing optimization settings, /Ox should do the trick:
[code]
00401016: 6808104000                     push        00401008 ;'Hello world!' --↑1
0040101B: FF1500104000                   call        printf
00401021: 59                             pop         ecx
00401022: 33C0                           xor         eax,eax
00401024: C3                             retn)

This code just calls printf and returns 0. So far, so good, but, did you consider to who you are returning?
Windows has traditionally placed a stub to ExitThread on the stack(

Application starts with top of stack looking like:
0012FFC4   7C816FD7  RETURN to kernel32.7C816FD7

7C816FD7    50              PUSH EAX
7C816FD8    E8 7B50FFFF     CALL kernel32.ExitThread), so you'd get the expected results (it also places a SEH handler and some other useful things), but it doesn't have to do any of that(it's undocumented behaviour), so a compliant Win32 application should call ExitProcess or ExitThread when they need to exit (or do it portably through libc).

>>39
try this, it should be a few bytes smaller:
#include <stdio.h>
int main(void){ return puts("Hello, World!"); }

>>40
Fuck off, ``faggot''.

>>43
* fuque off

>>43
All right, this shit HAS TO STOP !!

>>44
Allez à la France, ``salope''.

"GRUNNUR"

>>9
% ghc -O --make -dynamic Hello.hs -o Hello
[1 of 1] Compiling Main             ( Hello.hs, Hello.o )
Linking Hello ...
% du -h Hello
24K    Hello

>>9,48
Why do you use du -h instead of ls -l?

This way even I can make a "Hello World" bash script which may use several MB on a improperly formatted filesystem.

Or IABT?

>>49
Why do you use du -h instead of ls -l?
Why do you eat soup with a spoon even though you could easily pour it into a glass and sip it?

>>40
Friðrik Skúlason, in my /prog/?

section .data
  output db "Hello",10
  olen   equ $ - output

section .text
  global _start
_start:
  xor rax,rax
  inc rax
  mov rdi,rax
  mov rsi,output
  mov rdx,olen
  syscall

  mov rax,60
  mov rdi,0
  syscall

1082 bytes.

>>50
What if you want to know the file size, not the space it takes up? Huh? What now ``faggot''?

>>52
MOV MY ANUS

What if you want to know the file size, not the space it takes up?
du -hAB1

>>54
Almost got me there.

>>54
My du doesn't have an -A option, you BASH!

wc -c

what would hello world written in unix/windows asm come out to?

>>58
Few hundred bytes, in .com/.obj format few dozens.

>>58
.comm environ, 0
.comm __progname, 0

hello: .string  "Hello, World!"

.globl _start
_start:
        pushl   $hello
        call    puts
        call    exit

>>56
your toy operating system's du probably has an --apparent-size option that does the same thing.

>>61
My toy OS doesn't even have -B. Fuck Macs.

>>62
You do know Macs aren't meant to actually be used, right? You're supposed to just set it up somewhere conspicuous and admire it from a distance.

>>63
Steam on Mac... how did it get there?

>>62
*EMacs

uggBtAnNIcNIZWxsbywgV29ybGQhJA==

>>64
Dunno. Steve Jobs never approved it.


section    .text
    global    _start

_start:
    mov    eax, 0x4
    mov    ebx, 0x1
    mov    ecx, msg
    mov    edx, 0xF
    int    0x80

    mov    eax, 0x1
    mov    ebx, 0x0
    int    0x80

section    .data
msg:    dw    "Hello, world!", 0xa


 _________________________________________
/ Assembles and links to 364 bytes. Maybe \
\ you guys are doing something wrong!     /
 -----------------------------------------
     \
      \
             ,;;;;;;;,
            ;;;;;;;;;;;,
           ;;;;;'_____;'
           ;;;(/))))|((\
           _;;((((((|))))
          / |_\\\\\\\\\\\\
     .--~(  \ ~))))))))))))
    /     \  `\-(((((((((((\\
    |    | `\   ) |\       /|)
     |    |  `. _/  \_____/ |
      |    , `\~            /
       |    \  \           /
      | `.   `\|          /
      |   ~-   `\        /
       \____~._/~ -_,   (\
        |-----|\   \    ';;
       |      | :;;;'     \
      |  /    |            |
      |       |            |

>>68

 xchg bp, ax
 mov dx, .msg
 int 21h
 ret
msg:
 db "Hello world!$"

Assembles and links to 20 bytes. Maybe you guys are doing something wrong!

>>69

Something wrong has indeed been done!

>>69
In Windows you can't use ret. Its unpythonic.

>>71
ExitProcess is not required actually. It won't complain about 'ret' in some toy program.

>>72
See >>41 for an explanation on why it needs to be in a portable Win32 program. It's not truly required(ExitProcess) and will work fine in a lot of WINNTs, but it most certainly is not portable code(across Windows). Also, >>69's code is probably for 16bit DOS, but even there, you have to invoke an interrupt to terminate the program.

>>69
On Windows, that's simply not possible. The PE spec disallows programs smaller than 1024 bytes or somewhere in that region.

>>74
No, it doesn't, here's a (meaningful) example under:
http://blogs.securiteam.com/index.php/archives/675

You can probably get non-meaningful ones at ~150bytes.

If no special tricks are used, PE files generated by a C compiler and linked with the right flags and possibly re-aligned further can be gotten down to some 500-600bytes with ease.

>>69
>>66 already posted pretty much the same thing.

______________________________________
(>>69 still uses DOS 16-bit registers )
( and int 21h![code]                         )
 --------------------------------------
       o   ,__,
        o  (oo)____
           (__)    )\
              ||--|| *

>>77
right tool for the job