Re: [ECOS] i386/Windows target?

[Bart Veer <bartv at redhat dot com>]

>>>>> "Tom" == Tom M Yeh <tomyeh@infoshock.com> writes:

    Tom> TGlrZSBpMzg2L0xpbnV4IHN5bnRoZXRpYyB0YXJnZXQsIGlzIHRoZXJlIGEgV2l
    Tom> uZG93cyBzeW50aGV0aWMgdGFyZ2V0IHVuZGVyIGRldmVsb3Bpbmc/DQoNClJlZ2
    Tom> FyZHMsDQpUb20=

When sending to a public mailing list such as ecos-discuss, please
mail in plain text rather than using any form of encoding. People use
a wide variety of mail readers and may have problems deciphering
messages like the above.

    Tom> Like i386/Linux synthetic target, is there a Windows
    Tom> synthetic target under developing?

I know nobody within Red Hat is working on this. I am not sure whether
it is even feasible.

When building an synthetic target application you cannot link with any
of the host libraries. For example you cannot link with any of the
Linux C library because that would define a function malloc() which
clashes with the eCos libc malloc() implementation.

However the synthetic target application must still be able to make
certain system calls such as read() and write() so that it can
interact with the outside world. There must also be a way of setting
up incoming timer events to fake up a hardware clock, handled by alarm
signals in the Linux synthetic target, and in the near future there
must be some equivalent of SIGIO for use with pipes. On Linux none of
this is particularly difficult: all the required system calls can be
made by executing 0x80 traps, and details such as which arguments go
into which registers are readily obtained from the kernel sources.

From my limited knowledge of Windows, everything tends to happen by
linking with various DLL's so there is a good chance of a name clash
somewhere along the way. Presumably at some point there is a system
call mechanism that goes via traps, but I do not know the details or
how things vary between the different varieties of Windows.

There are also problems related to executable file formats. Linux uses
ELF, which provides all the functionality required by eCos. I believe
Windows still uses COFF, or some variant thereof.

It might be possible to solve these problems, but I suspect it would
require a lot of work.

Bart Veer // eCos net maintainer