please help this newbie running asm programs!!!

please help this newbie running asm programs!!!

[Seemanta Dutta]

greetings all linux gurus...
i am a newbie trying to port and run dos based 8086 programs under linux using as86, ld86 and elksemu.
i have written a simple program like

mov ah,09
lea dx,hello
int 21h

( i have omitted my directives here,,,but i have used .text, .code and of course _start: label )

so far i have been able to assemble my program with as86 but i am not able to link it using ld86. the linker says : no start symbol

am i missing something here?? i also studied the source code distro for bin86 
but could not find any example programs that can be assembled and linked using these tools...i am stuck badly...in case i am mising something here please tell me asap...i shall ever be grateful to you...if possible also send me a copied and pasted program that can be assembled and linked to run under elesemu, along with the necessary steps to make sure ld86 does not report any error messages during linking.
i thank u all in advance for ur help...

urs sincerely,
seemanta ;)

Re: please help this newbie running asm programs!!!

[Gábor Lénárt]

Hi,

I don't understand your point. It's quite useless what you're trying to do.
Why not run your DOS based program with DOSEMU? And what's the relation
between DOS programs and ELKS? I can't get your point sorry ...

On Thu, Jan 30, 2003 at 07:11:05PM +0530, Seemanta Dutta wrote:
> greetings all linux gurus...
> i am a newbie trying to port and run dos based 8086 programs under linux using as86, ld86 and elksemu.
> i have written a simple program like
> 
> mov ah,09
> lea dx,hello
> int 21h

OK.
Try it with NASM, beleive me, it's much simplier for you :)

->

[BITS 16]
org 100h
mov ah,9
mov dx,hello
int 21h
int 20h
hello DB 'Hello',13,10,'$'

This will work when assembled with NASM, and run under DOS as a simple .COM
file.

> 
> ( i have omitted my directives here,,,but i have used .text, .code and of course _start: label )
> 
> so far i have been able to assemble my program with as86 but i am not able
> to link it using ld86. the linker says : no start symbol

Yes, linker expect a starting symbol, it's quite normal otherwise which opcode
will be the first to execute? :)))

> 
> am i missing something here?? i also studied the source code distro for
> bin86 but could not find any example programs that can be assembled and
> linked using these tools...i am stuck badly...in case i am mising
> something here please tell me asap...i shall ever be grateful to you...if
> possible also send me a copied and pasted program that can be assembled
> and linked to run under elesemu, along with the necessary steps to make
> sure ld86 does not report any error messages during linking. i thank u all
> in advance for ur help...
> 
> urs sincerely,
> seemanta ;)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

writing programs for elks

[Alfonso]

Almost any 8086 language compiler can be used to write ELKS programs: 
nasm, dev86 (bcc or as86), Borland's Turbo C or Turbo Assembler (the 
TC 2.01 and Tasm 2.0 were made freeware on their site), etc.

I am writing a more complete article about this; I will place it here 
in some days. The only documentation I needed is found in these files:

  elks/fs/exec.c
  elks/Documentation/Text/memory.txt
  elks/Documentation/Text/bin_formats.txt

While DOS functions are accessed via INT 21h, the ELKS uses INT 80h 
(see the sources containing its definitions, e.g. strace.c)

Without using any strange tool, one can easily build an ELKS executable 
with up to 64k of code and up to 64k of data+heap (like the DOS 
"small" EXE model) just prepending a 32-byte header containing code 
and data segment sizes and other minimum information (see exec.c).

hi from south Italy!!
alf

Re: please help this newbie running asm programs!!!

[Alfonso]

> i am a newbie trying to port and run dos based 8086 programs under
> linux using as86, ld86 and elksemu. i have written a simple program

Under ELKS, you should use ELKS system calls (via INT 80h), instead of 
DOS calls (via INT 21h)...! :-)

If you want to port some DOS program, you must take into account that 
almost any program has to be modified and recompiled because:

- they assume DOS memory structures and interrupts (int 20h, int 21h, 
PSP, environment variables, etc)... ELKS programs are definitely 
*clean* with memory, hardware I/O, etc

- they assume DOS memory handling (i.e.: every program can use all 
remaining RAM upto 640k)... in ELKS, as in any Unix, a process cannot 
say "let's get all available RAM";

- they assume the can do everything with hardware; ELKS programs use 
the canonical "/dev/..." special files, and do not require special 
handling; i.e.: a screen terminal, a pipe, a disk file, a serial port, 
etc, everything uses the canonical open/read/write/close scheme (while 
DOS world uses a library for soundcard, the open/close for files; BIOS 
or write to screen-memory for terminal I/O, etc).

alf

writing programs for ELKS

[Alfonso]

Hi!!

I got a bunch of emails about my last messages, and try to answer to 
all questions here.


Re-entrancy: DOS system calls are not reentrant. This means that common 
DOS multitaskers (like DESQview) either emulate them in a reentrant 
manner (e.g.: reading a byte from the console is not that hard, but 
DOS makes it non-reentrant), or multiplex them with semaphores.

ELKS system calls are reentrant, because a task-switch can happen in 
every moment. As in every multitasked system, the calling process will 
be put to "sleep" while waiting for I/O (and, sometimes, while waiting 
for other higher priority operations).


Using Turbo C under ELKS means that we are accepting Turbo C limits 
(i.e.: the "int" type is 16 bit; features like floating-point math and 
overlay structure cannot be used without extreme special care, etc).

I did not consider Turbo Pascal because I do not know well its code 
generator and linker. The generated code must NOT contain far calls 
("extrasegment" calls) or interrupt calls. By using the "small" memory 
model, I am sure to have only one code-segment (upto 64k) and only one 
data-segment (upto 64k) without any need for segment override. That 
is, the program should never need to change the values in CS, DS, SS 
and -maybe- even ES (I cannot be sure that even the simplest Turbo 
Pascal program follows this rule). This is the reason why I defined a 
"clean" program to be an "upto 64k text, upto 64k data/bss/stack", and 
should not make any assumption about location of code segment, data 
segment, free memory, etc.


BSS means "bottom-stack space", and is the uninitialized space 
following the last byte of defined data. ELKS kernel wipes out it 
before starting the process, so that the uninitialized global arrays 
and variables are guaranteed to be zero-filled at the beginning. This 
is not always true in other environments, where BSS space is left 
uninitialized (so that the "startup code" has to wipe it... or, 
simply, warn the programmer that uninitialized data surely contains 
rubbish), and this is why C manuals warn about initialization.


In Linux and every other multitasked system processes are allowed to 
use memory only asking for it to the kernel. A task can use only what 
the kernel allowed for. Under Linux, if you try to access (even for 
reading a byte) other memory, the kernel gets an "exception" and kills 
the task before the operation is done (well, the signalling system is 
more complex, but it's guaranteed that any non-root process actually 
can't read and write anything out of explicitly authorized memory 
segments, files, etc).

ELKS cannot guarantee it, at least in the 8088/8086/80186 processors, 
because they do not have any memory protection instruction. An ELKS 
system has no true protection scheme (that is: it could be attacked by 
a decently written virus, even from a process without full root 
permissions), but remember that the "E" (embeddable) of "ELKS" means 
that you won't use it as a "let's try some dozens of new programs"...! 
Surely you will (re)build the entire system when you will add new 
changes...!
And - also - if you get a source program, you can check yourself if it 
does contain worms or viruses. This is the main reason why the viruses 
are an almost unknown phenomenon in the GNU-based world.


Yes, Turbo C is a nice thing, but, as everyone here, I like much more 
GPL-licensed software.

Re: writing programs for ELKS

[Dan Olson]

> ELKS cannot guarantee it, at least in the 8088/8086/80186 processors,
> because they do not have any memory protection instruction. An ELKS
> system has no true protection scheme (that is: it could be attacked by
> a decently written virus, even from a process without full root
> permissions), but remember that the "E" (embeddable) of "ELKS" means
> that you won't use it as a "let's try some dozens of new programs"...!
> Surely you will (re)build the entire system when you will add new
> changes...!
> And - also - if you get a source program, you can check yourself if it
> does contain worms or viruses. This is the main reason why the viruses
> are an almost unknown phenomenon in the GNU-based world.

There are two different problems that I see as a result of no memory
protection.  The first you mentioned, viruses and hackers trying to access
areas that they shouldn't have access to.  The other are poorly written
programs that accidently get into memory that's not theirs, and mess up
other processes/data.  Viruses "infect" executables and aren't part of the
source code, you might spot them by noting the files size of an executable
and seeing if it grows.  I think such things are really of little concern
to ELKS, as it's a) a very small percentage of the systems out there, and
b) not something we can fix.  If this is an issue, then using a CPU like
the 386 with Linux is probably more reasonable.  If do a good job keeping
bugs out of our code, we should be okay.  Just my 2 cents.

	Dan

Re: please help this newbie running asm programs!!!

[Phil Goembel]

Would the program start symbol also need to be _main,
or is that only needed by the C runtime library?

Phil

On Wed, 2003-02-05 at 17:16, Alfonso wrote:
> > i am a newbie trying to port and run dos based 8086 programs under
> > linux using as86, ld86 and elksemu. i have written a simple program
> 
> Under ELKS, you should use ELKS system calls (via INT 80h), instead of 
> DOS calls (via INT 21h)...! :-)
> 
> If you want to port some DOS program, you must take into account that 
> almost any program has to be modified and recompiled because:
> 
> - they assume DOS memory structures and interrupts (int 20h, int 21h, 
> PSP, environment variables, etc)... ELKS programs are definitely 
> *clean* with memory, hardware I/O, etc
> 
> - they assume DOS memory handling (i.e.: every program can use all 
> remaining RAM upto 640k)... in ELKS, as in any Unix, a process cannot 
> say "let's get all available RAM";
> 
> - they assume the can do everything with hardware; ELKS programs use 
> the canonical "/dev/..." special files, and do not require special 
> handling; i.e.: a screen terminal, a pipe, a disk file, a serial port, 
> etc, everything uses the canonical open/read/write/close scheme (while 
> DOS world uses a library for soundcard, the open/close for files; BIOS 
> or write to screen-memory for terminal I/O, etc).
> 
> alf
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_main and startup code

[Alfonso]

> Would the program start symbol also need to be _main,
> or is that only needed by the C runtime library?


The name "main" is internal to the C compiler and its libraries.

As of ELKS 0.1.1, an executable starts always at its CS:0000, where the 
bcc places the startup code (adjust stack parameters, call _main and 
then issue an "exit" syscall).

In the Minix-header there are two "Unused" fields. I found them defined 
somewhere as "starting address" and "lenght of symbol table (or DLL 
data) appended to the file".

Since the compiler sets them to zero by default, the patch below should 
be backward- and forward-compatible (I'm sorry, I don't know how to 
use those weird things like diff, patch, cvs, etc, so I show it to you 
in this jerky mode):


in the file  include/linuxmt/minix.h
change the line #23 from:
    unsigned long     unused;
to:
    unsigned long     startaddr;


in the file  fs/exec.c
add these lines after the line #348 (soon after "tregs->cs=cseg" line):
    tregs->ip = mh.startaddr;    /* guaranteed good at compile time */


This implements a "start address" eventually different from CS:0000.

But bcc won't support it. Every program compiled by bcc has a short 
initial startup section which rearranges argc/argv/envp parameters for 
calling _main (first part) and issue an _exit when main() returns 
(second part).

Yes, the "rearrange" could be easily implemented in the ELKS kernel. 
When the program terminates by exit() the second startup part is not 
needed. But if the main() returns a value, there is need for it.

An ugly hack could be patching the bcc in order to get the "main()" 
with a different stack frame; maybe something like:

_main: mov bp, sp                 ; opening code: not need to push bp

       [maybe: sub sp, NN -- stack space needed for local variables]
       [...rest of main()...]

       mov bx, ax                 ; closing code: bp is no more needed
       mov ax, 1
       int 0x80                   ; call exit(main())

This is transparent to the programmer except in the case of a recursive 
call to _main (well, in sixteen years of C programming I never found a 
case of a recursive _main call).

But this is an ugly hack because it needs a different stackframe for 
_main (the compiler should always check for the function name)...!


A decent hack should provide, when the main() returns, at least the 
three instructions of "closing code" of above. But this means either 
adding a "push return-address-to-closing-code" somewhere in the 
kernel, or... simply placing a "call _main -- closing code follows" at 
the beginning of the program (which can start at CS:0000 without any 
extra work).


I think I would not hack anything. The startup code often does a little 
more than calling _main and exiting with its return value. For example 
you could save in a static variable the envp so that a getenv() 
library function call can get in any moment (without _main support) an 
environment string.


These notes demostrate that, at least for C programs (not only bcc 
compiled programs), a "start address" different from CS:0000 is not 
really needed. Maybe a compiler for some other programming language 
could take some advantage from it.

We still did not discuss assembler-written programs. An assembler 
program does not always need to start at CS:0000 and/or with some 
startup code. The little patch of above seems suffice, but then I 
would add in the fs/exec.c a little extra check (to verify that 
mh.startaddr is less than mh.tseg).