Mail Archives: djgpp/2012/05/21/20:00:36
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. :-(
- Raw text -