Mail Archives: djgpp/2009/01/26/19:15:05
Hi Rod,
(BTW, I've still got a few comments on MOSS to send you)
On Jan 24, 8:35 pm, "Rod Pemberton" <do_not_h DOT DOT DOT AT nohavenot DOT cmm> wrote:
> "Rugxulo" <rugx DOT DOT DOT AT gmail DOT com> wrote in message
>
> news:1ce4ad0c-442e-421e-acb7-0e8abf5ffb3d AT f33g2000vbf DOT googlegroups DOT com...
>
> > On Jan 11, 3:50 am, "Blair Campbell" <blaird DOT DOT DOT AT gmail DOT com> wrote:
> > > Are there updated packages since 2006 available with better support
> > > for vista?
> ...
> > The problem is that Win7 shares the same Vista kernel / internals, so
> > things won't necessarily get better [for DJGPP and/or DPMI...]
>
> What do you recommend for DJGPP?
>
> Is there a future for DJGPP in environments which are eliminating or have
> eliminated DOS support?
>
> As I see it, DJGPP only has a few choices:
>
> 1) stay limited to DOS (and environments which support DOS boxes, e.g.,
> older Windows and Linux with DOSEMU and FreeDOS)
This is pretty much the status quo, and it requires no work, and I
think some of the smart guys of yesteryear are really really busy with
other stuff (and that's assuming they even still use DJGPP: some do,
some don't). So I'd wager this is where we'll stay without some
serious Jolt cola.
> 2) rework for portable DOS emulators such as DOSBox (I like, but DPMI
> disabled.)
DOSBox will even run on non-x86 cpus (e.g. even Mac OS X w/ PPC). The
problem is that it's only for games, has some issues, and is kinda
slow for normal DOS stuff. But it does have decent graphics and sound
emulation, maybe better than DOSEMU (which I admit I've only very
barely used).
> 3) rework for Windows console applications (Pelles C, LCC-Win32, MinGW,
> Cygwin...)
Kinda like RSXNTDJ, I guess. Of course, that's basically abandoned,
but I think it's niche was back before MinGW was stable (since
Cygwin's license is more restrictive). I tried it the other day for
the first time, and it seemed to work fairly well (dual DOS and Win32
apps). Of course, nobody seems to have 1.6 beta2 except the (slightly
truncated) archive on web.archive.org, which is kinda annoying. But
1.6 beta2 seems to be Win32 only (I guess preferring separate DOS and
Win32 compiles). EMX works well too (supposedly in OS/2 or DOS-
compatibles via RSX) but seems to be mostly abandoned. (The newer GCC
3.2.2 or whatever on Hobbes isn't DOS-compatible, so since I lack OS/
2, I couldn't run it. So I guess for that we're stuck with 2.8.1
unless there's some other version I'm unaware of.)
I dunno, compiling separately for each OS target seems like
reinventing the wheel, making too much work for ourselves. Some kind
of compatibility would be nice, maybe like Bryan Ford's Vx32 or
whatever.
> 4) rework for Linux (Why bother...? GCC toolchain.)
Since MOSS can read ELF, you've suggested there could be some
compatibility layer there. I don't think that's the worst idea. Also
Daniel Borca's DJGPP/ELF exists as well as Josh Vanderhoof's Cross-ELF
linker thingamabob.
> 5) create an "NTVDM" for Vista or port DOSEMU to Windows (NT's NTVDM was
> supposedly DOS 5.0 with some patches...)
I dunno, I would've hoped that MS would keep their NTVDM up to date or
at least still running, but I guess when you migrate everything every
few years, you lose interest. (Rumors keep abounding about various
things, e.g. eventually moving to all "managed" code and/or running
compatibility in a VM, etc.)
It's not really evil or disadvantageous to support other OSes
binaries, not sure why no one bothers. It's not impossibly hard to do,
I mean, people do it. I think people are too chauvinistic about their
host OS. We need to work together instead of being so stubborn about
minor nits.
> Various C compilers exist for Linux and Windows. So, the upgrade path, IMO,
> becomes environments where there aren't compilers and which support DOS,
> either DOS boxes or DOS emulation. I know DOSBox is intended for gaming and
> supposedly has DPMI disabled, but I like the idea of DOSBox since it should
> be free of v86 mode...
DOSBox is good, it just requires a ton of dependencies on Linux, for
instance. And you have to convince Linux distros to include it (which
some seem to not want to do). And it builds via C++, which adds more
complexity. But yeah, it runs okay.
- Raw text -