Message-Id:	<199603081117.GAA22305@delorie.com>
Date:	Fri, 08 Mar 96 13:07:34 LIT
From:	Martynas Kunigelis <martynas DOT kunigelis AT VM DOT KTU DOT LT>
Subject:	go32-V3
To:	DJGPP mailing list <djgpp AT delorie DOT com>

  I have a strange question to DJGPP developers, and it's kinda too late to
ask it, but let it be a rethorical question in such case:
 Why did you refuse the DOS-extender idea in V2? I know that go32-V1 had
many limitations because of those different modes it could run in (VCPI, XMS
etc.), but why not make a DPMI-only extender? It could do stub's job (running
CWSDPMI on need, loading the COFF image), things that crt0 and crt1 code does
now (wildcards, djgpp.env parsing, FPU, exceptions etc.), plus maybe some
basic file IO or other DPMI-based extensions, which would make libc smaller.
I think that kind of extender would significantly reduce the size of DJGPP's
bin directory, since for now we get such an extender linked into every V2
executable. Aaargh, what am I talking about. That would be DJGPP V3 :))

P.S.: can you point me a libc function that switches to real mode without
bothering my disk? I need to do a loop of RM switching for testing purposes.

Martynas Kunigelis

- Raw text -