The MASM Forum Archive 2004 to 2012

With a couple of guys we have a challenge who can write the smallest executable being able to print "Hello World".
Since the .com files would be the smallest possible, this is the current target.

Using a little trick (command line argument) I'm up to 7 bytes:

which can be run: test.com Hello World$
and it would print Hello World to the screen.

The only way I could come up with to make it another byte shorter is:

This should work the same, but gives an error instead:

I know I'm assuming an empty DH here, but when I run both versions through debug.exe the registers are identical (except for the IP which is off by one byte of course).
Shouldn't this just work or am I missing something here?

Any other ideas to make it even shorter?

Thanks!

This code gives me "05" as the result, so I guess DH isn't 0 after all...
You should really have a "ret" at the end of your code too.

strange, it gives 11 for me when I run your code, but when I run it through debug.exe:

Both AX and DX are 0 after the first line of code....
So debug.exe doesn't work like it should then?

I know about the ret that should be there, but it doesn't help in size :D

Thanks for your reply!

The only registers initialised by DOS for a .com program are AL,AH,DS,ES,SS and SP, all others are 'undefined' - they could be anything, usually what DOS left in there.
Debug initialises BX:CX to the program's size, maybe it zeroes out other registers? For me, debugging any program shows DX=0.

Debug zeros AX, DX, BP, SI, and DI by design.

Ahhh, so that explains why it looks ok.
Well, then 7 bytes really is the smallest we can go, I think.

Thanks for your answers!

Hi,

  Yes I just got bitten by the difference between DEBUG and
normal loading of a program.  Look at the GENERAL.TXT file
in the Hugi Compo rules for a good description of the start up
register contents.

http://www.hugi.scene.org/compo/

  The DI register was zeroed by DEBUG, which "fixed" an error
in my code.

Cheers,

Steve N.

Without the ret, I get a lot of garbage until it prints Hello. Are the rules of your game unspecific enough to tolerate the garbage?

Are you sure you have the $ at the end of the argument?
It works perfectly for me on vista. This the file (program) if you look at it from a hex editor:


And no it's not allowed to see garbage ;), but for me it doesnt......

Hey Prince Wotoshi. I see that you have a captains of crush gripper in your avatar. It was funny to see that there are grip trainers in this forum. I have closed the CoC 3.5 myself from a choked position and I have repped the CoC 3 from a non-choked position for about 6 reps.

Yes, I did a lot of grip training in the past :)
repping the #3 is a nice achievement, as well as closing the #3.5 from a choke. Good job!
I did both as well, but was not able to become COC certified. My small hands really gave me the disadvantage on the credit card set.
I got Mash monster certified with my #3 though, and the pic you see in my avatar is the #3.

I'm also red nail certified, but achieving that was a lot easier :)

But like I said, I did a lot in the past. Now I sometimes still do it, but I cannot close the #3 consistently anymore. Only on good days ;)

I have nails here myself. I havent trained much with them because I tend to run out of nails pretty quickly, and it takes a while to order new ones. I'm not in america. I bend blue nails very easily, but the red nail is not in reach yet.

I train with alot of equipment related to grip and forearm development. Here is a list of equipment/exercises I use frequently:

1: Captains of Crush grippers (I have dual sets of all of them)
2: Heavy Grips grippers (I have all of them)
3: Ironmind Wrist Roller (This one is really effective, it gives you a forearm pump like nothing else i've tried)
4: Ironmind pinch grip block (This one gets on the pinch grip)
5: Ironmind Rolling Thunder (I like this one)
6: Hammer Bar (I ordered this from an armwrestling store, its an effective tool, you mount weight plates onto it)
7: Hercules Bar (This is also a good forearm developer)
8: I use normal weight plates in my hand and curl them with my wrist, I can almost handle 15 kg plates now)

My bench press is really bad at the moment, but my deadlift is 280 kg and my squat is 210 kg. Overhead press is 100 kg x 3 reps so far.
Bicep curl is 90 kg x 3 reps at most.

My strongest area is definitely deadlift. I am trying to improve my bench, I can barely handle 120 kg in the bench. I have very long arms, it could be because of that i'm not sure.

Anyways, good day!

BTW: I understand the emotional situation one can get into after years of training. You get tired, cant afford enough protein, motivation is lost etc. It takes effort to get back into a good pattern again. I struggle with this myself.

you must keep in mind that interrupts are executable code.
this i think may be smaller. works only for text mode.

      mov ax,0b800h
      mov es,eax
      lea esi,HelloString
      mov edi,0
      mov cx,sizeof HelloString
loop:
      lodsb
      mov ah,07h ; not sure if attr should be ah or al long time no DOS
      stosw
      dec cx
      jcxz end_loop
      jmp loop
end_loop:
      int 20h

  Not sure how this stiff works anymore . It gives invalid fixup .

37 bytes, 15 of code?

i think you need the 8th byte...
as for relying on DH=0, not sure that is a valid assumption under NTVDM

  yeah,... well lets not forget that int 21h is a far call. So there's code beneath the instruction... Is it smaller? Don't know....
    bye

that is true however, .COM programs are executed similar to a NEAR CALL
the reason a RETN instruction exits is that an INT 20h instruction is at CS:0000 and a 0000 pushed on the stack at program entry
(CS = PSP)

  ok ... i'm not sure we're understanding each other. If i do this...


...is everyone going to disregard the code parts in this procedure call?
  No? Yay, ive won!!!
  LMAO :)

Did you talk about 16 programs only, or for Win32, too?

  i think its DOS only antariy

Well, if it been Win32, then I can suggest a candidate...

It's .com, actually... and it's 8 bytes short:

If that looks too complex, try this:

Batch file for testing:


Which one?

You are know  :lol
But it not only print HelloWorld  :wink

I can suggest to put code into command line specification, and at start of the program put the 2 byte jump to the command line  :wink

So, you just needed to avoid binary null in the code (this is easy), and enter the code as command line for the 2 bytes program, which just jump to command line.

But I must warn that under Windows this is a bit tricky due to encodings difference. So, this is reliablest from DOS.

Command line is something like (in hex, convert it to dec and enter it with Alt codes):

The program is:

jmp 82h but...:

There is a test with 2 byte program which print HelloWorld.
To simplify things with different encodings, is written an .BAT file.
On my system it works.


Alex

Thanks, Alex - works like a charm on Win XP SP2...

Update in .BAT file - pause>nul

It actually prints "Hello,World" for me, not space but comma, is that legal? :lol

(I tried it with space and that worked also :lol)

PS. Does that mean I technically win :lol

This is correct - I used not space.

For pure historical DOS, there is one more update  :lol



Alex

Any idea why jmp word ptr ss:[82h] does not work?

Because this is level of inderection - you jump not to address 82, but to address, which is specified in WORD placed at address 82.
I guess my English not help...

By the way, you can enter very very very long (up to ~110 chars) string for printing - and this will have no influence for program size  :bg

P.S. you can edit .BAT file because it contain only printable chars.

Alex,

Your program + .bat file works on Vista (32-bit) too.

Thank you, Greg!

This "EB 80" 2-byte program was also discussed in the FASM forum:

http://board.flatassembler.net/topic.php?t=10847

here's the clean Masm version, without tricks like "JMP $-7Eh":


to be linked with "link16 /tiny ..."

there is nothing wrong with this method, either...
of course, you can use a Start: label instead of a _main proc, if you prefer

thing is - if you need a batch file to get the results, i say you have defeated the purpose of the contest   :P

You don't need a batch file, actually. But you should know how to use Alt nnn at the DOS prompt :bg

i know how to do it   :P
but, who can remember the sequences   :lol
it reminds me of booting a tape drive on a PDP11 with the front panel switches
a sequence which i, at one time, had memorized - now happily forgotten

at any rate, the point of the post: you don't need to open a segment at 0 for the PSP
the code segment naturally encompasses the PSP in a .COM program

You're right. I had the idea that with the AT segment there is no risk that a linker adds 256 null- bytes to "fill" the gap, but this isn't necessary. Also, some linkers won't accept an AT segment in a group.

Well, since I saw that other programs uses passed string as Message, that why I cannot use passed string for code?
The program itself is just vulnerable application, which allow execution of arbitrary code, code in shell-style. :P

So, my version is just from model line of: "http://www.masm32.com/board/index.php?topic=10252.msg125593#msg125593"  :wink



Alex

I'm have nothing to say contrary. For 30 years of DOS existence, I'm sure - thousands of peoples reinvent the same many times.



Alex

My post was merely informational.

No problem, I'm understand that  :U



Alex

yes - that may happen if you stuck anything more than a label there
over the years, using different versions of different assemblers...
you can sometimes get away with DW ? - sometimes not
ORG xx LABEL DWORD or ORG xx BranchLabel: always seem to work

the only time i have used SEGMENT AT is when i wanted to access the interrupt vector table (even then it isn't needed)
or when writing ROMable code
it matters if you want to generate proper segment values in far addresses

as i said, it isn't needed when accessing the IVT, because i generally do not access that memory in 0000:0000 context
rather, i use something like XOR AX,AX - MOV DS,AX - then access the vector offsets