X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rugxulo <rugxulo AT gmail DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: incompatible
Date: Mon, 21 May 2012 16:43:58 -0700 (PDT)
Organization: http://groups.google.com
Lines: 83
Message-ID: <06733c3b-deb0-460e-bae0-955dcd48fc93@n42g2000yqm.googlegroups.com>
References: <16cd2 DOT 48279178 DOT 3ce778e4 AT aol DOT com> <b0b0ab18-82a4-4f25-934a-bf2823485517 AT dg7g2000vbb DOT googlegroups DOT com>
 <DsudnQvgGtmp-iXSnZ2dnUVZ_vednZ2d AT earthlink DOT com> <83bolizxdh DOT fsf AT gnu DOT org>
 <a9198f82-451b-491c-a3d9-66fde801d216 AT e20g2000vbm DOT googlegroups DOT com>
 <e48708a0-7a65-47aa-a26e-ce329f292e62 AT v10g2000vbe DOT googlegroups DOT com>
 <8dabbc83-5370-4b8a-b278-82fd10e325e2 AT s5g2000vbc DOT googlegroups DOT com>
 <4370c769-d25c-4b75-8d4e-006a8dfb5290 AT n16g2000vbn DOT googlegroups DOT com> <d11c46b9-3c62-4535-ab20-a7867db5f490 AT m3g2000vbl DOT googlegroups DOT com>
NNTP-Posting-Host: 65.13.115.246
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1337643838 28833 127.0.0.1 (21 May 2012 23:43:58 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Mon, 21 May 2012 23:43:58 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: n42g2000yqm.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16
 (KHTML, like Gecko) Chrome/10.0.630.0 Safari/534.16,gzip(gfe)
Bytes: 5117
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q4M002bH008538
Reply-To: djgpp AT delorie DOT com

Hi,

On May 21, 4:46 pm, Georg <dos DOT  DOT  DOT  AT googlemail DOT com> wrote:
> On May 21, 10:56 pm, RayeR <gl DOT  DOT  DOT  AT centrum DOT cz> wrote:
>
> > Yes, RSX/NT but I never tried it. I also think that watcom can do it
> > or is it my misremember?
> > It seems to me impractical to use extra DLL and extender.

That's what you're doing behind the scenes anyways for HX (HXRT w/
HDPMI32).

> > Also it  is
> > probably a hack to some older djgpp source.

Right, RSXNT hasn't been updated since 1999, heh. I only tested with
old 2.x GCC, and I doubt languages besides plain C work well, if at
all.

>> We would need something
> > that could be easily patched to recent gcc, binutils, djdev... without
> > much extra effort to allow update it again when newer versions will be
> > released.

The only obvious way I can think of is separating the actual libc into
a .DLL where it would load one for DOS and one for Windows while
keeping the .EXE itself the same. Of course, I think this is more or
less what HX does except it puts all the DOS support in (fake) Win32
kernel DLLs, etc.

Yes, HX works well but obviously doesn't support all the newer Windows
features, and of course not nearly all Win32 files will work 100%
(e.g. Cygwin won't). But it's surprisingly good for what it does.
(Much more limited support for such Win32 emulation was also supported
in WDOSX extender, which always required PE relocs.) At least
OpenWatcom doesn't rely on MSVCRT, so that's good.

> > But it may be hard due to DJGPP dependency on DPMI and DOS
> > calls so in this case it may be better to make some NTVDM-like
> > extension for win64 cmd

Yes, I guess? somebody could port DOSEMU to Win64. If it can work
under Linux 64-bit, it could work under Windows too. Far better than
nothing.

> > (e.g. with using those mentionex VTX - I don't
> > know details how it works and if it's helpfull for 16bit code). It
> > would be much comfortable to run DJGPP programs directly via cmd
> > instead of loading some VM with DOS inside separated from host
> > filesystem and taking long time to load.

VT-X does (depending on version) support "paged real mode" or
"unrestricted guest execution (real mode, big real mode)".

You can allegedly share DOS files via MS NET in VBox or VMSMOUNT in
VMware. And of course DOSBox does it natively (but has other
limitations).

But no existing solution is perfect.

> > I think if Japheth could
> > write win32 support for DOS it shouldn't be harder to make DOS/DPMI
> > support for win64 if VTX can help instead of missing V86...
>
> I do not know much about RSX/NT but upgrading a part of it could be
> less effort than writing a NTVDM.

You're basically using two libcs anyways, so you could argue that it's
not worth it beyond just separate compiling two .EXEs anyways. I think
this is why more people haven't bothered.

Another more simplistic "solution" would be to just write in a
scripting language that is well-supported on both platforms. Then you
don't have to worry at all about libcs, binary formats, or other junk.
I realize that's not what we really want here, but I suspect this is
another (workaround) "solution" promoted by common folks.

> The Win7 command window already features DPMI as standard, at least
> the ones I tried.

Win7 doesn't support DPMI except under 32-bit editions, and it has the
same bugs (e.g. DPMI limit, no gfx) as Vista. Better than nothing ...
but not much.   :-(