Mail Archives: djgpp/2013/06/26/13:15:06
Hi,
On Wednesday, June 26, 2013 3:05:30 AM UTC-5, Rod Pemberton wrote:
>
> > I don't know what "port MinGW to DOS" means,
> > but I'm very very skeptical.
>
> Basically, I was asking how difficult it would be to create a DOS
> only version of MinGW.
Which part? Presumably you mean borrowing (or using)
some parts of the libc. Or did you mean specific
tools? Or just support for compiling Windows programs?
I hate to say it, but overall it's probably too
complicated (and of dubious usefulness).
> If MSVCRT has many functions and MinGW
> uses many of them, it'll take much coding to remove or replace
> them. If the MSVCRT functions MinGW uses are complicated, not
> simple, it'll take even more work. Some C libraries only need
> about 20 functions to bootstrap, while others need many.
Do you want a DJGPP-hosted MinGW environment? Or are
you thinking of running some of this under HX?
> If yet another DOS C compiler is needed, it might be better to get
> the DOS versions of LCC, versions 3.5 and 3.6, working again.
> Then, migrate useable updates from 4.1 and 4.2 back.
Detlef Reimers already ported LCC 4.2 to DOS via DJGPP.
It uses NASM (COFF) and DJGPP's (BinUtils) ld linker
and older libc (2.01). He deleted his website, but I
could upload it somewhere for you. He also ported EiC
(interpreter) to DJGPP. (I would say "just email him",
but ....)
> Or, it might be better to de-Linux-ify TCC, e.g., remove the dlopen
> and dlsym related code, do test compiles with DJGPP, and figure out
> how to bootstrap later, perhaps with the old TurboC.
TinyC was originally Linux only, so it has some weird
kludges in there. IIRC, even on Win32 it used ELF
for .o files! It's not easy to rebuild (at least IMHO),
and when I tried with DJGPP, it didn't fully work
correctly.
Honestly, I think something like PCC would ideally be
better to port. But porting something like Nils Holm's
SubC (subset) is more realistic.
> If Japheth ignores it, rejects it, or doesn't have time for it,
> then I could package up one with the exe. Then, you could do me
> yet another favor and mirror it on your website (lol).
My Google Sites website isn't very useful. iBiblio mirror
of FreeDOS is a better idea, IMO, though it's all the
same to me.
> However, I
> was hoping the code could be reviewed by someone skilled in x86 and
> experienced with Himemx too, like Japheth, Devore, or some of the
> guys on DOSX, before being hosted on iBiblio, on Japheth's site, or
> on your site.
Of course, I thought the same (else I'd have already
mirrored it!). :-)
Tom Ehlert is still vaguely active, so maybe he'll
look at it, but outside of him, I don't know who else
would be interested. (Eric Auer seems absent these
days. Devore has been AWOL for a long time, but maybe
one of us could email him, if desperate.)
> My main concern is I can't test some of the really
> old machines HIMEMX works on. I also can't currently test the
> machine it was intended for. I may get it working by this fall.
> So, I just don't know if I introduced any unintended errors.
Japheth's already replied that he can't test multiple
blocks either.
Well, as long as it doesn't regress for current DOS
users, I guess that's as good as we can hope!
- Raw text -