Mail Archives: djgpp/2009/01/07/12:01:41
Hi,
On Jan 6, 5:11 am, "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
>
> Well, another good post Rugxulo.
Let's go for 2/2. :-)
> > The latest
> > DOSEMU for GNU/Linux emulates the 16-bit stuff under 64-bit mode,
>
> I think the best solution would be DOSEMU ported to Vista, using FreeDOS as
> the required DOS. IIRC, the latest DOSEMU builds using libSDL, so I'd think
> this is doable, if not already done...
DOSEMU also needs S-Lang2, IIRC. But I have no idea when DOSEMU was or
ever will be compiled for Windows.
> > The stub is 16-bit,
>
> You could unstub...
Sure, but I see no advantage there.
> > and the C lib does call BIOS and MS-DOS interrupts
>
> ... but you can't fix that easily.
It can't be that hard. I mean, people write JIT compilers and VMs all
the time (e.g. Ruby or Perl).
> > Cygwin has lots of ports of stuff, so you
> > can't really go wrong there (right, DJ?). ;-)
>
> Yeah, DJGPP is "dying"... Like, the other day, I needed to assemble and
> disassemble some 64-bit GAS code to reply to a newsgroup post, but 64-bit
> code was disabled in DJGPP's binutils.
Cygwin and MinGW aren't exactly perfect either, still stuck to old
versions due to .DLL and exception issues (as well as the always-
problematic lack of maintainers).
Anyways, there have been a (very) few attempts at a 64-bit DOS
extender, but they're mostly proof of concept and don't do anything
(or even return cleanly). Hence 64-bit is less interesting to DOS
users (esp. no V86 mode). But there are DOS ports of certain tools
that support it. (Good luck building a DJGPP cross-compiler for it!
GCC is kinda complex / annoying to rebuild.) At the very least are
Agner Fog's ObjConv and Nick Kurshev's BIEW, both of which have DOS
ports. I'm not aware of other 64-bit tools (besides NASM, FASM, YASM,
obviously).
> ELF support in binutils and an ELF target, perhaps "i386-elf" or
> "i386-generic-ELF", would help OS developers who are using DJGPP.
But there was a COFF bootloader at one time, right? (I know you know
more than me on this since I don't write OSes, heh.) But yeah, ELF is
pretty ubiquitous, so having some support in DJGPP can't hurt.
> Of course, I'd expect code produced for the ELF target to be pure 32-bit or
> 64-bit, even if non-functional... I'd prefer that the split memory model,
> i.e., application address space and below 1Mb, be kept. At some point, I'd
> like to see the standard GLIBC used for DJGPP. This would require much of
> DJGPP's POSIX and LFN related libc code patched "underneath" GLIBC. This
> would improve software compatibility, reduce porting issues, keep GNU
> utilities current, etc., although it'd eliminate much of "DJGPP" itself.
It would only optionally replace it. Remember that the DJGPP/ELF third-
party experimental hack kept both COFF and ELF support. (And boy, -
static ELF is much bigger than COFF, sheesh. WTF?!)
> If a suitable compile target is available, this "compatibility layer" might be
> doable entirely in the DOS DPMI host and/or 16-bit .exe stub, allowing use
> of completely stock GLIBC. There is some history to support that this is
> possible, see the MOSS DPMI host:
>
> http://www.cs.utah.edu/flux/moss/moss.html
= "Mach on DOS" (Bryan Ford)
= GPL, compiles fully with GPL tools, uses subset of FreeBSD libs so
free for almost any use
= not updated since 1996
= (old) Linux binaries (GCC 2.7.2) are dynamically linked (doh), don't
run on Slackware 11
= no real-world examples anywhere (or at least I couldn't find 'em)
= currently no (obvious, automatic) way to bind .EXE and a.out ELF
file into one (although possible)
= GCC 3.3 (and similar timeframe BinUtils) still had (leftover)
support for it, but I dunno after that
> Since it seems MOSS uses an *almost* stock GCC and GLIBC, I'd think a port
> of MOSS to DJGPP might help in creating a complete, stock GCC and GLIBC
> combination that works on DOS
MOSS might be too minimal for GLIBC, and some things are pretty hard
to port. Or at least, people with the *nix mindset have a hard time
(apparently), even if they are willing (which they usually
aren't). :-/ I've heard it said that DOS is only viable for
games, but nobody seems to be writing many of those anymore. Maybe
just a subset of GLIBC would prove worthwhile, but I'm not
qualified. :-(
> I'd suggest removing any code that might
> bypass DJGPP, e.g., the Flux OS toolkit code. I think MOSS might run on
> other DOS DPMI hosts like CWSDPMI, so I'd probably remove VCPI, EMS, and any
> unecessary DPMI, etc. code. Then, the MOSS DOS extender will compile as a
> standard DJGPP application, it would then use CWSDPMI and DJGPP's POSIX and
> LFN's, etc. which are probably more up to date and likely have fewer errors.
Assuming you want to recompile all of that "POSIX and LFN's" for ELF
(which will break a few things, e.g. unexec).
> Since MOSS.EXE is 38k, the resulting "conversion layer" after coreing should
> be very small, perhaps small enough that it could be added to CWSDPMI.
MOSS.EXE is limited to 64k (although they claim they knew how to
overcome it but never mentioned, only pointed to now-nonexisting
mailing list), so 38k + 20k for CWSDPMI = pretty close to the limit
(tight assembly probably needed).
> It seems that MOSS is using the following "primitives" or syscalls:
It would be interesting to see an actual app running via MOSS, but
that requires rebuilding the toolset (which I failed at doing last
night, blech). At least MOSS.EXE comes precompiled, but it didn't like
the ELF .o that DJGPP/ELF made, so ....
> MOSS has C wrappers to call the following DPMI functions. It doesn't use
> five or so of them. Three are DPMI 1.0, but only two are used. Of the DPMI
> 1.0 calls, one is supported by CWSDPMI and one isn't:
Although I think they should speak for themselves, I heavily suspect
CWS is too busy / disinterested. Same for DJ. There aren't a lot of
qualified DPMI authors anymore.
> 1687 (2f), 0, 6, 7, 8, A, B, C, D, 202, 203, 204, 205, 300, 400, 501, 502,
> 504, 505, 509, 600, 601, 604
You know way more about DPMI than I do, so surely you know how hard it
is. ;-)
- Raw text -