Message-Id: <200007210832.KAA07828@mailgw3.netvision.net.il>
Date: Fri, 21 Jul 2000 11:32:16 +0200
To: Nick DiToro <NDiToro AT ati DOT com>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
In-reply-to: <5337D585DDD3D111996B0008C728F07DA42A4B@pa00fsr01.pa.atitech.com>
	(message from Nick DiToro on Thu, 20 Jul 2000 20:10:30 -0400)
Subject: Re: Watcom vs djgpp
References:  <5337D585DDD3D111996B0008C728F07DA42A4B AT pa00fsr01 DOT pa DOT atitech DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Nick DiToro <NDiToro AT ati DOT com>
> Date: Thu, 20 Jul 2000 20:10:30 -0400
>
> 1) How tough is it to port Watcom code?

It depends.  Some factors that might matter:

  - does the source use inline assembly?

  - how much of the source accesses memory-mapped hardware by using an
    absolute address, like this:

	     char *video = (char *)0xa00000;

  - how much of the code calls real-mode interrupts through int86 or
    int386 and their ilk, and expects them to transparently support
    buffers in protected-mode memory?

  - does the code install interrupt handlers?

All of those factors will require more work to make the port.

I suggest to study chapters 17 and 18 of the DJGPP FAQ list
(v2/faq230b.zip from the usual DJGPP sites).  It should give you some
idea about the issues mentioned above.  You can ask specific questions
later.

> Porting the assembly code is going to stink because
> of the different formats used.  Has anybody had to do this in the past?

Yes, many people did that many times.  See sections 17.1-17.4 of the
DJGPP FAQ list, and especially section 17.2, for more info and some
pointers.

> 2) We sometimes run Watcom executables under Win 9x in a DOS box.  As long
> as win 9x does not grab and use the hardware we are running the diagnostic
> on, this seems to work fine.  Is this possible with CWSDPMI ?

You cannot use CWSDPMI on Windows, and neither should you need to.
Unlike DOS4GW, CWSDPMI is not a DOS extender, it is merely a DPMI
server.  You don't need it on Windows because Windows has its own
built-in DPMI server.

As to whether a DJGPP program can access hardware on Windows: it
depends on what access to what hardware do you want.  Please
elaborate.

> 3) I am aware of RHIDE, and like it.  However, we have a remote debugging
> situation where gdb would be useful, and having the xxgdb front end
> available would be SUPER useful.  I think this is possible if we go over the
> serial port and use a Sun, but I have never done it.  Can we do this with
> the DJGPP version of gdb?

Someone posted here a couple of weeks ago an announcement about a
DJGPP stub for remote debugging with GDB over a serial link.  Look up
that announcement at this URL:

  http://www.delorie.com/djgpp/mail-archives/

Note that xxgdb front end is not ported to DJGPP (AFAIK).  You will
need to use the command-line interface.

> 4) I would like to learn more about DJGPP and the go 32 DOS extender.

DJGPP doesn't include go32 extender anymore, it belongs to an older
v1.x version of DJGPP that is long unsupported and undeveloped.

> DJ's web site has been a great resource.  Can anybody point me to
> any other resources (other than those listed on the web site)?

Did you read the following?

  http://www.delorie.com/djgpp/doc/eli-m17n99.html

> (Books, magazine articles, etc.)

We wish...