Author Topic: The smallest executable  (Read 38247 times)

Vortex

  • Member
  • *****
  • Posts: 2337
Re: The smallest executable
« Reply #30 on: January 18, 2013, 06:14:16 AM »
Creating small executables is interesting also while working with HLLs.

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: The smallest executable
« Reply #31 on: January 18, 2013, 07:36:05 AM »
Creating small executables is interesting also while working with HLLs.

But the EXE files generated by compilers are not so small.

Gunther
Get your facts first, and then you can distort them.

jj2007

  • Member
  • *****
  • Posts: 10547
  • Assembler is fun ;-)
    • MasmBasic
Re: The smallest executable
« Reply #32 on: January 18, 2013, 08:27:00 AM »
But the EXE files generated by compilers are not so small.

Erol is a genius, he can produce a 1.5k C executable. The problem with such tiny programs is that a) they can't fill a hard drive sector (4k) and b) they don't do anything useful (but wait until Alex logs in :lol:)

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #33 on: January 18, 2013, 02:11:38 PM »
I've done some refinement to the code, and got rid of about
20 instructions, sparing some 50-60 bytes, but still not sufficient
to reduce the size to 2K. It's actually fixed at 2,5K.

I've seen that there is a lot of space for size reduction, so the 2K
goal is quite feasible.

Attached the shrinked version 0.4.

Frank

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #34 on: January 18, 2013, 04:59:29 PM »
In order to get rid of the .data section altogether, I need
to transform this line of .data:
Code: [Select]
ConTitle  db " -----------   **  Extended ASCII chart displayable characters  **  ----------", 0

in a line of LOCAL to put inside the PROC that uses it.

I have no clue how to do it. Any help is welcome.

dedndave

  • Member
  • *****
  • Posts: 8827
  • Still using Abacus 2.0
    • DednDave
Re: The smallest executable
« Reply #35 on: January 18, 2013, 05:01:21 PM »
it doesn't need to be local
what you want is to put it in the code section

if you did want it to be local, you could push it onto the stack in reverse order - very clumsy

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #36 on: January 18, 2013, 05:13:46 PM »
it doesn't need to be local
what you want is to put it in the code section

if you did want it to be local, you could push it onto the stack in reverse order - very clumsy

I want to put it in the .code section, but I don't know how.
How I define it, where I put these bytes?

dedndave

  • Member
  • *****
  • Posts: 8827
  • Still using Abacus 2.0
    • DednDave
Re: The smallest executable
« Reply #37 on: January 18, 2013, 05:18:22 PM »
stick it any place you like, really - someplace where it won't be executed   :P
Code: [Select]
DisplaySequence ENDP

ConTitle  db " -----------   **  Extended ASCII chart displayable characters  **  ----------", 0

; -------------------------------------------------------------------------
; Writes the Screen Title with enhanced color attribute White on Magenta
;--------------------------------------------------------------------------

WriteScreenTitle PROC

as a matter of practice, i try to define things earlier in the source than where i use them
that isn't always practical

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #38 on: January 18, 2013, 05:23:11 PM »
stick it any place you like, really - someplace where it won't be executed   :P
Code: [Select]
DisplaySequence ENDP

ConTitle  db " -----------   **  Extended ASCII chart displayable characters  **  ----------", 0

; -------------------------------------------------------------------------
; Writes the Screen Title with enhanced color attribute White on Magenta
;--------------------------------------------------------------------------

WriteScreenTitle PROC

as a matter of practice, i try to define things earlier in the source than where i use them
that isn't always practical

In this way the .data section is not created? Because this is my goal here.

dedndave

  • Member
  • *****
  • Posts: 8827
  • Still using Abacus 2.0
    • DednDave
Re: The smallest executable
« Reply #39 on: January 18, 2013, 05:24:53 PM »
if there is nothing left in the .DATA section, don't use .DATA and it won't be created

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #40 on: January 18, 2013, 05:28:58 PM »
if there is nothing left in the .DATA section, don't use .DATA and it won't be created

OK, good.  :t My .data section is empty and deleted from the program,
but nothing changes in the size of the prog. 2,560 bytes  ::)

frktons

  • Member
  • ***
  • Posts: 491
Re: The smallest executable
« Reply #41 on: January 18, 2013, 05:47:12 PM »
The prog without the .data section attached. Anyone can see where I can
save some other bytes?


jj2007

  • Member
  • *****
  • Posts: 10547
  • Assembler is fun ;-)
    • MasmBasic
Re: The smallest executable
« Reply #42 on: January 18, 2013, 08:03:05 PM »
DisplayFmt PROC szFmtName:DWORD
LOCAL rc:SMALL_RECT
  movlps xmm0, windowSize        ; make a copy
  movlps rc, xmm0
  INVOKE WriteConsoleOutput, wHnd, szFmtName, DWORD PTR bufferSize,
  DWORD PTR startPoint, addr rc                ; offset windowSize crashes the app
  ret
DisplayFmt ENDP

sinsi

  • Guest
Re: The smallest executable
« Reply #43 on: January 18, 2013, 09:15:50 PM »
If they don't change then put them in .code
Of course, some APIs will expect to write to it...

offset windowSize crashes the app

Quote from: MSDN
lpWriteRegion [in, out]
A pointer to a SMALL_RECT structure. On input, the structure members specify the upper-left and lower-right coordinates of the console screen buffer rectangle to write to. On output, the structure members specify the actual rectangle that was used.


jj2007

  • Member
  • *****
  • Posts: 10547
  • Assembler is fun ;-)
    • MasmBasic
Re: The smallest executable
« Reply #44 on: January 18, 2013, 10:22:41 PM »
On output,

Indeed, see movlps above. Strange that it apparently did not crash on Frank's machine.