Smallest .COM 'Hello World' in MASM
Rohit Tripathi
.model tiny ; We want a .COM file
.code ;
org 100h ; .COM file start address
mov dx,offset helloS ; ( 3 )
xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
int 21h ; ( 2 )
ret ; ( 1 )
helloS db 'Hello, World!$' ; ( 14 )
.end ;
When i compile it with the ORG directive, i get a 277 byte file.
However if you remove the ORG, you'd get a 21 byte file.
FYS
Hi Rohit,
What assembler are you using? 21 + 100h = 277
NBASM creates a 21 byte file with or without the ORG 100h.
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Forever Young Software
http://www.cybertrails.com/~fys/index.htm
To reply by email, please remove the zzzzzz's
Batteries not included,
Some assembly required.
"Rohit Tripathi" <scorpi...@yahoo.com> wrote in message
news:7b4f978d.02010...@posting.google.com...
Ozone Radical
you forgot to mention that it prints nothing. I think the original
program has some bug too
Rohit Tripathi
Though I compiled the program, I didn't get a proper output.
I am sorry if I say something offensive at times. I am here to learn,
so please pardon me.
"FYS" <zf...@cybertrails.com> wrote in message news:<008301c197bd$75229ba0$43722aa2@oemcomputer>...
Jonathan Kirwan
(Rohit Tripathi) wrote:
>Hi, I was using ML 6.15 (the one with VC++ service pack 5)
>Though I compiled the program, I didn't get a proper output.
Try:
.model tiny
.code
.startup
mov dx,offset helloS
xchg bp,ax
int 21h
ret
helloS db 'Hello, World!$'
end
The ".end" you wrote doesn't work in ML 6.15. You can use .startup
instead of using ORG and an END statement with a label. Here's
another alternative:
.model tiny
.code
ORG 100h
mystart: mov dx,offset helloS
xchg bp,ax
int 21h
ret
helloS db 'Hello, World!$'
end mystart
Just tested these under 6.15. Works okay.
Jon
debs
On Mon, 7 Jan 2002 22:55:58 +0000 (UTC), Ozone Radical spake thus:
>> When i compile it with the ORG directive, i get a 277 byte file.
>>
>> However if you remove the ORG, you'd get a 21 byte file.
>
>you forgot to mention that it prints nothing. I think the original
>program has some bug too
If you download nasm and use that to assemble it, you will get the 21
byte file that writes 'Hello, World!' to a command prompt. I just
tested it under Windows 2000 to make sure that it still works with the
initial value of BP, and it does. You will need a couple of minor
changes to make it work under nasm:
remove the '.code' and '.model tiny' from the start of the file.
remove the 'offset' from the first line of code (it will now read
'mov dx,helloS'.
If you save it as 'hello.asm' you can assemble with:
nasm hello.asm -o hello.com
You can then type 'hello' at a command prompt (in the directory/folder
that the file is in) and it will print 'Hello, World!' to the screen.
Someone who uses masm will have to tell you how to create the file
with masm :)
As FYS said, it is the smallest executable file you will get to print
that string to the screen at a command prompt.
--
debs
de...@dwiles.nospam.demon.co.uk
----
Misspelled? Impossible! I have an error correcting modem.
Matthias Paul
>> .model tiny ; We want a .COM file
>> .code ;
>> org 100h ; .COM file start address
>>
>> mov dx,offset helloS ; ( 3 )
>> xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
How do you come to use this???
>> int 21h ; ( 2 )
>> ret ; ( 1 )
>>
>> helloS db 'Hello, World!$' ; ( 14 )
>>
>> .end ;
I don´t know what operating system you´re under, but BP is undefined
when you start a .COM program, no wonder that it does not work in
most cases... You must not rely on it to contain 09xxh, so you will
still need the MOV AH,09h.
The offical startup specification for a .COM program is:
CS,DS,ES,SP = PSP segment
IP = 100h
AL = 00h if standard FCB 1 has a valid drive specifier,
FFh if invalid
AH = 00h if standard FCB 2 has a valid drive specifier,
FFh if invalid
SP = FFFEh or the maximum size of memory,
whatever is smaller
00FEh on very old DOS issues (DOS 1.xx and/or 2.xx probably)
BX, CX, DX, SI, DI, BP, Flags, and the high words on 386+ CPUs
are undefined officially.
The stack holds a WORD of 0000h (so that the RETN works).
This is what is supported by MS-DOS, PC DOS and DR-DOS,
but you should not rely on the AH and AL values on RxDOS
and FreeDOS.
Under RxDOS 6.0 AL and AH are always 00h and under DOS-C
(the FreeDOS pre-decessor) they are always FFh (I haven´t
checked current sources, things might have changed meanwhile).
Under RxDOS 6.0 CX:BX hold the size of the program, just
like under DEBUG.EXE, but under DOS-C these registers
are preset to zero. DX, SI, DI, BP are all set to zero
under RxDOS and DOS-C, but not under MS-DOS/PC DOS/DR-DOS
(at least not officially).
EOL equ ´$´
;INT_TERM equ 20h ; DOS Terminate
INT_DOS equ 21h ; DOS API
;DOS_TERM equ 00h ; Terminate program
DOS_WRITESTR equ 09h ; Write string to STDOUT
;DOS_GETVER equ 30h ; Get DOS version
;DOS_EXIT equ 4Ch ; Terminate with return code
ORG 0100h
start: mov ah,DOS_WRITESTR
mov dx,OFFSET message
int INT_DOS
ret
message db "Hello World!",EOL
Greetings,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
FYS
> Though I compiled the program, I didn't get a proper output.
>
> so please pardon me.
Hi Rohit,
The MASM 5.10 code that I posted before and the code that Jon
posted in another message should assemble correctly with
version 6.15.
Remember that you "must" use a segmented linker. I use LINK
version 3.69.
As for the offensive bit, don't worry about it. I don't :)
[ Pun intended ]
mov eax,CR0
or eax,OFFENSE_BIT_TRUE
mov CR0,eax
Ben
FYS
"Matthias Paul" <Matthi...@post.rwth-aachen.de> wrote in message
news:a1e75n$du2$3...@nets3.rz.RWTH-Aachen.DE...
> On 2002-01-07, "Ozone Radical" wrote:
Hi Matthias,
> >> xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
>
> How do you come to use this???
>
> I don´t know what operating system you´re under, but BP is undefined
> when you start a .COM program, no wonder that it does not work in
> most cases... You must not rely on it to contain 09xxh, so you will
> still need the MOV AH,09h.
<snipped>
[ A small explanation to this was posted a few hours ago, and has
yet to show, so maybe I will post a more detailed explanation :) ]
Since this thread spawned from the "Hugi Compo" thread, I am still
talking about the "Hugi Compo" (HC).
With in the HC group, we want to find every little byte that we can
ever find, so the values of the registers at start up are an excellent
source of optimization possibilities.
So, around HC2, we came up with a rule that stated the values
of all registers whether defined or undefined. Then, if an entry
was built on a machine that did not contain some or all of these
values, on could write a small .if/.endif block to set these registers
while building the entry. Then when the entry was built, simply
tell the assembler not to assemble the register definition code
(.if/.endif block).
We needed a set register value for all registers to make it fair
for all entrees.
Now, on a different side, run the following code on your machine,
whether under a DOS box or in TRUE DOS (any brand).
;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
; assembled with NBASM
.model tiny
.code
.186
org 100h
mov ax,bp
call prthex
.exit
prthex proc near uses ax cx dx
mov cx,04
PLoop: rol ax,04 ;
push ax ;
and al,0Fh ;
daa ;
add al,0F0h ;
adc al,40h ;
mov ah,02 ;
mov dl,al ;
int 21h ;
pop ax ;
loop PLoop ;
ret
prthex endp
.end
;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
What does it print as BP? On every machine I have tried it on,
I get the high byte of BP set to 09h.
Granted, all my machines are Windoze 9x or below, or MS-DOS 5.0
or below. (Didn't try it on my Win2k machine)
Again, not to be rude or anything, you have a perfect argument here.
I am just stating that since this thread spawned from the "Hugi Compo"
thread, and we can assume BP = 09xxh in any HC entry, I stated
BP = 09xxh in my "Hello, World!" entry. :)
If my other (smaller) message shows, it too states that for all
"Hello, World!" entries outside of the "Hugi" compos, you must use
'mov ah,09'.
On a different note, we also had a compo via "Martin Flynn's Compos",
where we had to display the value of all (16-bit) registers to the
screen with the smallest code. Funny thing is, we displayed SS
in place of BP (using PUSHA). I was about to get some code from
that compo to show you, but then realized we replaced the BP with SS,
and it wouldn't do any good here :)
( Martins' compo's are at:
http://groups.yahoo.com/group/assembly_contests/files/contests.htm
watch for wrapping. )
Regards,
Ben
P.S. Looks like my other message(s) just showed :-)
FYS
"Matthias Paul" <Matthi...@post.rwth-aachen.de> wrote in message
news:a1e75n$du2$3...@nets3.rz.RWTH-Aachen.DE...
> On 2002-01-07, "Ozone Radical" wrote:
>
> >> xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
>
> How do you come to use this???
>
A follow-up to my previous message:
MS DOS 5.0 091Ch
MS Win2k DOS box 091Eh
MS Win98SE DOS box 0912h
MS Win95OSR2.x DOS box 09xxh
I went to try the PCDOS machine sitting here,
and it is having troubles with the HDC. I might
pull the drive out and place it in another machine
to get the PCDOS version and BP value if I
feel energetic enough :)
See ya,
Ben
Stipe Galic
>.model tiny ; We want a .COM file
> .code ;
> org 100h ; .COM file start address
>
> mov dx,offset helloS ; ( 3 )
> xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
> int 21h ; ( 2 )
> ret ; ( 1 )
>
>helloS db 'Hello, World!$' ; ( 14 )
>
> .end ;
Maybe you can write this smaller . Put helloS on very beggining of program,
do a xchg si,dx (si = 100h) and adjust string so no branching, pushing or
changing bp&si occures (play with lower and upper cases, or h@X0R it :)
And put 'hello world$', and you'll get 17B sized program .
>
>When i compile it with the ORG directive, i get a 277 byte file.
>
>However if you remove the ORG, you'd get a 21 byte file.
This is MASM problem and I have no clue how to solve it.
Frank Kotler
>
> >.model tiny ; We want a .COM file
> > .code ;
> > org 100h ; .COM file start address
> >
> > mov dx,offset helloS ; ( 3 )
> > xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
> > int 21h ; ( 2 )
> > ret ; ( 1 )
> >
> >helloS db 'Hello, World!$' ; ( 14 )
> >
> > .end ;
>
> Maybe you can write this smaller . Put helloS on very beggining of program,
> do a xchg si,dx
Okay. Not as short as the xchg with ax, but okay...
> (si = 100h)
Are we "guaranteed" this?
> and adjust string so no branching, pushing or
> changing bp&si occures (play with lower and upper cases, or h@X0R it :)
> And put 'hello world$', and you'll get 17B sized program .
Can we see it? I've got this foolish little thing - 16 bytes - it
doesn't do anything if you run it, but it says hello if you view it as
text - not quite the same thing.
;----------------------------------
; assemble with "nasm -f bin -o hitext.com hitext.asm"
; view with "type hitext.com"
;----------------------------------
dec ax
inc bp
dec sp
dec sp
dec di
sub al,20h
push di
dec di
push dx
dec sp
inc sp
or cl,[di]
int 20h
;---------------------
> >
> >When i compile it with the ORG directive, i get a 277 byte file.
> >
> >However if you remove the ORG, you'd get a 21 byte file.
>
> This is MASM problem and I have no clue how to solve it.
As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
think that Nasm is a good choice for this type of work - direct binary
output with no linker or exe2bin involved - I don't know why the "more
powerful" assemblers don't have this option.
As for bp "always" (apparently not!) being 09xx - it works for me. Ed
Beroset posted a program a while ago to display the register values at
startup (I've got a Nasm "translation" of it, of course :) I've also got
a boot-sector that does nothing but display the registers as they were
at boot-up (roughly). Holler if you want either, anybody.
Best,
Frank
FYS
Aahh, now you are thinking like a true "Hugi Compo" contestant :-)
However, one of the main rules is that you can not crash the
machine by doing something "inappropriate".
db 'Hello, World!$'
does some INSB and OUTSB stuff. Depending on what CS is
(DX = CS on .COM entry), it could trash the machine.
Second, 'Hello, World!' would be a constant string by a
given rule. :) (i.e. Must be set, no changes)
Ben
"Stipe Galic" <rea...@hotmail.com> wrote in message
news:a1in1n$cj74$3...@as201.hinet.hr...
>
> >.model tiny ; We want a .COM file
> > .code ;
> > org 100h ; .COM file start address
> >
> > mov dx,offset helloS ; ( 3 )
> > xchg bp,ax ; ( 1 ) (bp = 09xxh at .COM startup)
> > int 21h ; ( 2 )
> > ret ; ( 1 )
> >
> >helloS db 'Hello, World!$' ; ( 14 )
> >
> > .end ;
>
> Maybe you can write this smaller . Put helloS on very beggining of
program,
> do a xchg si,dx (si = 100h) and adjust string so no branching, pushing or
> changing bp&si occures (play with lower and upper cases, or h@X0R it :)
> And put 'hello world$', and you'll get 17B sized program .
>
>
> >
debs
On Thu, 10 Jan 2002 05:56:04 +0000 (UTC), Frank Kotler spake thus:
>As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
>think that Nasm is a good choice for this type of work - direct binary
>output with no linker or exe2bin involved - I don't know why the "more
>powerful" assemblers don't have this option.
Coz in reality they aren't all that powerful. They just provide money
for the people who sell them, and everyone knows:
MONEY EQU POWER
Nasm is for those of us who know how to write assembly code and don't
need the assembler making assumptions about what we want it to do :Ź)
Ed Beroset
>> >
>> >When i compile it with the ORG directive, i get a 277 byte file.
>> >
>> >However if you remove the ORG, you'd get a 21 byte file.
>>
>> This is MASM problem and I have no clue how to solve it.
One solution is to specify an starting address.
org 100h
start:
; ... code goes here
end start
>As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
>think that Nasm is a good choice for this type of work - direct binary
>output with no linker or exe2bin involved - I don't know why the "more
>powerful" assemblers don't have this option.
Using MASM: "ml hello.asm" results in the indicated 21 byte program
so the more powerful assemblers do already have this option.
>As for bp "always" (apparently not!) being 09xx - it works for me.
Yes, it's going to work often, but I prefer programs that work always!
I'd like to know *why* the high half of bp is going to be 0x09, for
instance. If you recall, there were a lot of date routines that
worked correctly for many many years, right up to 1 January 2000...
>Ed Beroset posted a program a while ago to display the register values at
>startup
It's funny, but the reason I wrote it was specifically to illustrate
the point that you can't rely on having specific values in specific
registers like BP. The source for that program is on my web site (
http://www.beroset.com ) and is called showregs.asm. If you look in
the comments at the top, you'll see that the registers and values that
*are* guaranteed and hopefully you'll know to avoid the ones that
aren't.
>(I've got a Nasm "translation" of it, of course :)
Feel free to post it if anybody wants it -- I donated the original
TASM source to the public domain when I wrote it back in 1995.
Ed
Frank Kotler
> >As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
> >think that Nasm is a good choice for this type of work - direct binary
> >output with no linker or exe2bin involved - I don't know why the "more
> >powerful" assemblers don't have this option.
>
> Using MASM: "ml hello.asm" results in the indicated 21 byte program
> so the more powerful assemblers do already have this option.
I *wondered* if it was just because I didn't know how to use 'em :) Why
do people always post solutions using exe2bin???
> >As for bp "always" (apparently not!) being 09xx - it works for me.
>
> Yes, it's going to work often, but I prefer programs that work always!
Right! I didn't mean to imply that it was safe to use (except in a
"compo" where the rules specify that you *can* count on it, of course).
It reinforces a point that (I think it was) Terje raised - there's a big
difference between the smallest *possible* program, and the smallest
reasonably "robust" program (well, only a byte in this case :). Remember
that "compo" that Alexei proposed a while ago, to swap the first and
last bytes in a file? Doing *any* kind of intelligent error-handling on
that would have doubled the size of the code, or so...
> I'd like to know *why* the high half of bp is going to be 0x09, for
> instance.
Good question. Or why si "often" seems to be 100h - I might expect di to
be length-of-program plus 100h (+ 1, probably) after dos gets done
loading us, but it doesn't appear to be. I don't think I'm curious
enough to disassemble command.com to find out. It is what it is.
> If you recall, there were a lot of date routines that
> worked correctly for many many years, right up to 1 January 2000...
Ah yes, the date that was going to change the world forever.
> >Ed Beroset posted a program a while ago to display the register values at
> >startup
>
> It's funny, but the reason I wrote it was specifically to illustrate
> the point that you can't rely on having specific values in specific
> registers like BP. The source for that program is on my web site (
> http://www.beroset.com ) and is called showregs.asm. If you look in
> the comments at the top, you'll see that the registers and values that
> *are* guaranteed and hopefully you'll know to avoid the ones that
> aren't.
>
> >(I've got a Nasm "translation" of it, of course :)
>
> Feel free to post it if anybody wants it -- I donated the original
> TASM source to the public domain when I wrote it back in 1995.
Yes, all your comments, and the donation are still there. The
"translation" consisted mostly of commenting out the "end proc"s and
such. The Tasm/Tlink command lines given are:
; TASM showregs ; assemble file
; TLINK /Tdc showregs ; link as DOS COM program
Is there a way to get Tasm to output straight binary directly? If so,
why does everybody use Tlink? For the symbol files for TD?
Best,
Frank
Nexter
Actually you dont need the --> ! sign on the end to print ( hello World ),
so in actual fact the smallest hello program would be 20 bytes.
model Tiny
.Code
org 100h
strt:
mov ah,9h
mov dx,offset mg
int 21h
ret
mg db'Hello World!$'
end strt
Ed Beroset
>Ed Beroset wrote:
>
>> >As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
>> >think that Nasm is a good choice for this type of work - direct binary
>> >output with no linker or exe2bin involved - I don't know why the "more
>> >powerful" assemblers don't have this option.
>>
>> Using MASM: "ml hello.asm" results in the indicated 21 byte program
>> so the more powerful assemblers do already have this option.
>
>I *wondered* if it was just because I didn't know how to use 'em :) Why
>do people always post solutions using exe2bin???
Earlier versions of MASM generated only object modules, IIRC. The two
possibilities would be to generate a COM file using the linker, or to
generate an executable and then convert it using exe2bin. I haven't
used exe2bin in a couple of centuries, though, so I don't really
recall if it had any particular advantage over the former method or
the one I suggested.
>> >As for bp "always" (apparently not!) being 09xx - it works for me.
>>
>> Yes, it's going to work often, but I prefer programs that work always!
>
>Right! I didn't mean to imply that it was safe to use (except in a
>"compo" where the rules specify that you *can* count on it, of course).
>It reinforces a point that (I think it was) Terje raised - there's a big
>difference between the smallest *possible* program, and the smallest
>reasonably "robust" program (well, only a byte in this case :).
Yes, that's the thing. One can set things up so that it works always,
by explicitly loading registers which cannot be relied upon to have
specific values, or one can make assumptions which work some of the
time.
>Remember that "compo" that Alexei proposed a while ago, to swap the first and
>last bytes in a file? Doing *any* kind of intelligent error-handling on
>that would have doubled the size of the code, or so...
Unfortunately, that means a usable program is almost never the result
of such exercises. It's a shame, really, because not only do you not
get a reliable program, but you also don't usually get anything as
entertaining to read as the infamous obfuscated C contests.
>> I'd like to know *why* the high half of bp is going to be 0x09, for
>> instance.
>
>Good question. Or why si "often" seems to be 100h - I might expect di to
>be length-of-program plus 100h (+ 1, probably) after dos gets done
>loading us, but it doesn't appear to be. I don't think I'm curious
>enough to disassemble command.com to find out. It is what it is.
You don't have to disassemble command.com. You can look at the source
for Caldera's DR-DOS: http://www.drdos.net/download.htm In that
source, you'll find the loader in an assembly module called cstart.asm
and a routine called cdos_exec. That's a start anyway, but it's not
the whole picture of course. As an example, here's a simple C
program, compiled using Borland C version 4.02 which I happen to have
handy:
-+--- spawn.c begins
#include <stdio.h>
#include <process.h>
int main(int argc, char *argv[])
{
execl(argv[1], argv[1], NULL);
return 0;
}
-+--- spawn.c ends
When I run it as "spawn showregs" it shells out and runs showregs.com
and the results on this machine are:
AX = 0000
BX = 00FB
CX = 0BDA
DX = A000
DI = 0000
SI = 1240
BP = B400
CS = 0C0D
DS = 0C0D
ES = 0C0D
SS = 0C0D
CS, DS, ES, and SS (and the IP value which isn't shown) are as
documented and the other registers are completely different values
than if I run showregs from the command line on the same machine:
AX = FFFF
BX = FFFF
CX = 00FF
DX = 0C0D
DI = FFFE
SI = 0100
BP = 0912
CS = 0C0D
DS = 0C0D
ES = 0C0D
SS = 0C0D
The moral of the story, of course, is that it's generally not a good
idea to make unwarranted assumptions about register values! (But I
know you already know that, Frank.)
>> If you recall, there were a lot of date routines that
>> worked correctly for many many years, right up to 1 January 2000...
>
>Ah yes, the date that was going to change the world forever.
Didn't it? The cost *just in the US* was US$100 billion. Globally,
the estimates range from $320 to $500 billion. (see
http://www.senate.gov/~y2k/documents/final.pdf )
I don't know about you, Mr. Gates, but that's a lot of money to some
of us!
>Yes, all your comments, and the donation are still there. The
>"translation" consisted mostly of commenting out the "end proc"s and
>such. The Tasm/Tlink command lines given are:
>
>; TASM showregs ; assemble file
>; TLINK /Tdc showregs ; link as DOS COM program
>
>Is there a way to get Tasm to output straight binary directly? If so,
>why does everybody use Tlink? For the symbol files for TD?
I don't really use TASM much any more, but the way it was back in '95
when I wrote that program, TASM produced only object modules and you
still needed to run a linker.
I've got a copy of TASM 5 still in the shrinkwrap, but I haven't
bothered to open it, so I don't know if the later version follows the
MASM (or now ml) method of calling the linker automagically, and
frankly it wouldn't matter to me anyway really, since I always use a
makefile anyway.
Ed
Matthias Paul
Oops, SS I meant, not SP. Sorry.
Beth
> Ed Beroset wrote:
> > Using MASM: "ml hello.asm" results in the indicated 21 byte program
> > so the more powerful assemblers do already have this option.
>
> I *wondered* if it was just because I didn't know how to use 'em :) Why
> do people always post solutions using exe2bin???
Because...ummm...maybe they don't know how to use 'em, either...hehehe :)
Beth ;)
Stipe Galic
Frank Kotler wrote in message <3C3CFF85...@ne.mediaone.net>...
>Okay. Not as short as the xchg with ax, but okay...
Right. That's now 18B ... damn:))
>
>> (si = 100h)
>
>Are we "guaranteed" this?
:) No. I just >>executed string<< and you worry about that ?! :) But it
works under MSDOS.
>
>> and adjust string so no branching, pushing or
>> changing bp&si occures (play with lower and upper cases, or h@X0R it :)
>> And put 'hello world$', and you'll get 17B sized program .
>
>Can we see it? I've got this foolish little thing - 16 bytes - it
>doesn't do anything if you run it, but it says hello if you view it as
>text - not quite the same thing.
Well here's what I've got. I tryed manually to adjust string, but no succes.
Than I wrote a program that compiles this Hello World in all possible
combinations(upper and lower case) and I got 2MB disassembly of
hello.com(who sed .com can be only 64kB large:) , and I need
to find the combination where xchg ax, bp occures, but I can't find one
because Word says that there is no xchg ax, bp . Ofcourse there IS
xchg ax, bp only Word doesn't see it:((
>
>As a Nasm-bigot, I'd say the solution is Nasm :) Seriously, I really
>think that Nasm is a good choice for this type of work - direct binary
>output with no linker or exe2bin involved
I agree.
- I don't know why the "more
>powerful" assemblers don't have this option.
More powerful? Oh you mean "more powerful", right, right ... ;)
>
>As for bp "always" (apparently not!) being 09xx - it works for me. Ed
>Beroset posted a program a while ago to display the register values at
>startup (I've got a Nasm "translation" of it, of course :) I've also got
>a boot-sector that does nothing but display the registers as they were
>at boot-up (roughly). Holler if you want either, anybody.
--
Stipe Galic
1024x768x256? Sound like one mean woman!
Stipe Galic
FYS wrote in message <005701c19980$fbf6be80$5a722aa2@oemcomputer>...
>
>Aahh, now you are thinking like a true "Hugi Compo" contestant :-)
:)
>
>However, one of the main rules is that you can not crash the
>machine by doing something "inappropriate".
It won't crach mashine. Mine one, that is :)
>
> db 'Hello, World!$'
>
>does some INSB and OUTSB stuff. Depending on what CS is
>(DX = CS on .COM entry), it could trash the machine.
>
>Second, 'Hello, World!' would be a constant string by a
>given rule. :) (i.e. Must be set, no changes)
All those rules will make your programming life boring :) Someone once
sed that programming is replacement for sex. Well I just took out my leather
wip:))
>Ben
Heiko Möllerke
best to be a part of it ;o)
the question should be:
"how much space do we effectively need to display a 'hello world' on
screen?"
the above sollution "only" works on ms-compatible systems. does anybody know
how much memory the int0x21(ah=9) needs? - we should add this amount of
memory to our calculation.
-Heiko-
Jerry Coffin
says...
Here's one that I believe depends only upon (reasonably) PC-
compatible hardware being present, that you have a color (rather than
strictly MDA) compatible display adapter (which is currently in a
color mode), and that a 'ret' at the end of the program will do
something sane like returning you to the OS.
Note that this doesn't do anything tricky, so it's possible that
somebody might be able to do a bit better. Nonetheless, the code is
only 19 bytes, of which 4 bytes is immediate data. If you don't mind
restricting the output to one specific color, you can reduce that to
17 bytes pretty easily.
In any case, it's fairly easy to produce the desired output on a PC
without a lot of extra code. As a fringe benefit, this code will
normally run a LOT faster.
Of course, that's not a direct answer to your question, but there
probably is no one direct answer to your question -- the exact code
in the int 21h dispatcher has changed over the life of DOS, and it
depends on the BIOS to do the real output. The BIOS, of course, has
varied over the life of the machine AND from one BIOS vendor to
another, so it's almost impossible to predict how much code is really
involved without knowing the EXACT machine you want to talk about,
and even then it would take some fairly careful use of a debugger to
figure out exactly how much code got executed.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
Chewy509
"Jerry Coffin" wrote in message
> > it seems, that this discussion become a neverending-story... so i'll do
my
> > best to be a part of it ;o)
> >
> > the question should be:
> > "how much space do we effectively need to display a 'hello world' on
> > screen?"
> >
> > the above sollution "only" works on ms-compatible systems. does anybody
know
> > how much memory the int0x21(ah=9) needs? - we should add this amount of
> > memory to our calculation.
>
> Of course, that's not a direct answer to your question, but there
> probably is no one direct answer to your question -- the exact code
> in the int 21h dispatcher has changed over the life of DOS, and it
> depends on the BIOS to do the real output. The BIOS, of course, has
> varied over the life of the machine AND from one BIOS vendor to
> another, so it's almost impossible to predict how much code is really
> involved without knowing the EXACT machine you want to talk about,
> and even then it would take some fairly careful use of a debugger to
> figure out exactly how much code got executed.
>
approximately 720bytes of code to do a simple "Hello World" type output...
Maybe we should extend this to: Smallest "Hello World" in MASM without using
DOS or BIOS routines.
Chewy509...
Richard Pavlicek
> Maybe we should extend this to: Smallest "Hello World"
> in MASM without using DOS or BIOS routines.
This reminds me of a silly challenge years ago.
The following is not exactly a "Hello World" program,
but it's similar and uses no DOS or BIOS interrupts.
It is assumed that ax = bx = 0, and si = 100h.
The COM program is 21 bytes.
ORG 100h
MAIN:
inc di
dec di
and [bx+65],al
push sp
dec di
push dx
push bx
xchg di,ax
mov ax,0B876h
mov es,ax
MAINL:
lodsb
stosw
inc ax
jpe MAINL
ret
Can you guess what it does? Hint: I'm a Univ. of
Florida alumnus.
If you're concerned about the "and" line, it merely
trashes a useless byte in the PSP. Also, note that
segment es is loaded with an address that falls in
the standard vider buffer, so it writes harmlessly
to the screen.
--
Richard Pavlicek
Web site: http://www.rpbridge.net
Richard Pavlicek
> Maybe we should extend this to: Smallest "Hello World"
> in MASM without using DOS or BIOS routines.
This reminds me of a silly challenge years ago.
Johan Kwisthout
Er, it writes (part of) the program code as ascii to the screen, in my
screen it writes GO GetORS. Don't know what 'ORS' means...
>If you're concerned about the "and" line, it merely
>trashes a useless byte in the PSP. Also, note that
>segment es is loaded with an address that falls in
>the standard vider buffer, so it writes harmlessly
>to the screen.
What about the JPE? how does this work?
Johan.
Arargh!
(Johan Kwisthout) wrote:
<snip>
>>Can you guess what it does? Hint: I'm a Univ. of
>>Florida alumnus.
>
>Er, it writes (part of) the program code as ascii to the screen, in my
>screen it writes GO GetORS. Don't know what 'ORS' means...
Misspelled 'gators' ?
>
>>If you're concerned about the "and" line, it merely
>>trashes a useless byte in the PSP. Also, note that
>>segment es is loaded with an address that falls in
>>the standard vider buffer, so it writes harmlessly
>>to the screen.
>
>What about the JPE? how does this work?
--
Arargh (at arargh dot com) http://www.arargh.com
Richard Pavlicek
> Er, it writes (part of) the program code as ascii to the screen,
> in my screen it writes GO GetORS. Don't know what 'ORS' means...
That's weird (assuming you typed it correctly). Here is
the listing file I get (using MASM ver 6.11 or 5.1):
0100 ORG 100h
0100 47 MAIN: inc di
0101 4F dec di
0102 20 47 41 and [bx+65],al
0105 54 push sp
0106 4F dec di
0107 52 push dx
0108 53 push bx
0109 97 xchg di,ax
010A B8 B876 mov ax,0B876h
010D 8E C0 mov es,ax
010F AC MAIN1: lodsb
0110 AB stosw
0111 40 inc ax
0112 7A FB jpe MAIN1
0114 C3 ret
Note that the bytes through offset 0108 (if interpreted
as ASCII) spell "GO GATORS" (all upper case).
> What about the JPE? how does this work?
It simply takes advantage of the lucky fact that all the
letters in "GO GATORS", when incremented, produce even
parity -- except the final S. How con-VEEN-ient, as the
Church Lady would say. :)
--
Richard
Johan Kwisthout
<ric...@rpbridge.net> wrote:
>Johan Kwisthout
>
>> Er, it writes (part of) the program code as ascii to the screen,
>> in my screen it writes GO GetORS. Don't know what 'ORS' means...
>
>That's weird (assuming you typed it correctly). Here is
>the listing file I get (using MASM ver 6.11 or 5.1):
>0102 20 47 41 and [bx+65],al
I entered it in debug, which assumes hex... It was GO GeTORS actually.
>Note that the bytes through offset 0108 (if interpreted
>as ASCII) spell "GO GATORS" (all upper case).
>
>> What about the JPE? how does this work?
>
>It simply takes advantage of the lucky fact that all the
>letters in "GO GATORS", when incremented, produce even
>parity -- except the final S. How con-VEEN-ient, as the
>Church Lady would say. :)
0x65 plus one is parity even as well... So it worked at my PC at well.
Nice trick, actually.
Johan.