Mail Archives: djgpp/2009/01/11/23:30:38
"Rugxulo" <rugxulo AT gmail DOT com> wrote in message
news:4563e62e-7382-4c6a-b986-d4c8a8ff9d47 AT i18g2000prf DOT googlegroups DOT com...
> 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
> >
> > > 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.
>
S-Lang? Ok, another C like interpreter... It's interesting to note that it
fully supports C's types which some of the other more well known and closer
to true C interpreters don't.
> > > The stub is 16-bit,
> >
> > You could unstub...
>
> Sure, but I see no advantage there.
>
Just to get rid of the 16-bit code... so the application is 32-bit only (or
mostly so). Sorry, I was thinking you said 32-bits could run "at the same
time as 64-bit stuff."
Previously, you said:
> AMD64 long mode doesn't allow 16-bit
> programs to run at the same time as 64-bit stuff. Only the emulation
> mode allows 16- and 32-bit stuff (but no 64-bit then).
Are you sure about this? Once in long mode, the code size 16/32/64 is
selected by bits in the CS selector. If it works like legacy mode, you
should be able transfer to the new selector by jmp or gate etc. to switch
instruction size while remaining in long mode.
> > > 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).
Well, I had a specific method/situation in mind when I stated that: the
aforementioned Vista 64... For DOS, you'd just need a 64-bit DPMI host.
Using a 64-bit port/compile of DOSBox, if available, might be easiest for
Vista. But, what I was thinking about is when running on an OS, you'd need
to trap all the DPMI calls that DJGPP uses. That likely requires installing
interrupt routines or binary patching of the code. After trapping the DPMI
calls, you'd also need to decode them to get the DOS and BIOS calls. Then,
you need to translate all the DOS and BIOS calls to the OS's API.... All of
that is done in DOSBox already for whatever systems it supports.
> > 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).
>
Well, I've not done much for Windows. I had problems with Cygwin and MinGW.
I don't recall trying LCC-Win32. I've not used OpenWatcom for Windows.
But, I did have good luck with "the other LCC" compiler, Pelles C, but it
was a console application.
http://www.smorgasbordet.com/pellesc/
> 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
Well, hopefully for DOS, it should just be a matter of rewritting the 32-bit
DPMI code for 64-bit.
> Agner Fog's ObjConv
Aware of it, haven't used it. Those who have seem to swear by it.
> Nick Kurshev's BIEW
Except for assemblers and compilers, I usually use more primitive tools...
DOS EDIT for most editing. A DOS clone of VI to add/remove from
beginning/end of multiple lines, or, GAWK scripts for files that are too
large for VI. An ancient and no longer available text editor for hex
editing that I'll leave unnamed... ;) My own text and binary programs in C
for anything else: splitting/joining, hex dump/undump, text filters, etc.
--
One tool I have become fond of for my personal OS work is John Fine's
Partcopy. It eliminates rawread/rawrite, etc. It uses a different syntax,
but is equivalent in functionality to *nix's dd command which, AFAIK, has
never been fully ported or implemented on DOS. NASM is another...
> > 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.)
Actually, you had me stumped... After a quick check, I found quite a few
COFF related programs by Chris Giese and Alexei Frounze, including
bootloaders... I'm not sure to which you're referring though.
(I wrote this prior to your 3/3 post....)
> But yeah, ELF is
> pretty ubiquitous, so having some support in DJGPP can't hurt.
But, ELF is supported natively by GCC and Multi-boot bootloaders, of which
there are a few CG's MBLOAD, GRUB, DOS4GRUB, etc.
> > 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?!)
I haven't used Daniel Borca's version yet. I'll probably try it eventually
just to check out ELF support. Of course, we should expect dynamic ELF from
DJGPP... ;-)
> > 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
True. Well, I think DJGPP uses about 170 DOS, BIOS, DPMI calls. I've
attempted to determine the number of "primitives", the underlying function
calls, that are required to build GLIBC, but I had problems. Linux 2.6.17
Kernel uses 290 syscalls, so GLIBC must use fewer. I didn't count other
recent versions, but there was a large increase in the number Linux versions
used just prior to that, so at most I'd figure half that. I'd figure most
the important ones came first and very early. Linux 0.01 has about 40
completed syscalls. Even at half the 290 figure, I'd think the estimate is
really high since Redhat's newlib and PJ Plauger's standard C library only
require 18-20 functions to implement, but they are ANSI/ISO C and have no
POSIX... My guess is 50-110 and hoping for the low side.
> I've heard it said that DOS is only viable for
> games, but nobody seems to be writing many of those anymore.
Well, I think there are a few groups of DOS users who don't comingle much:
programmers (DJGPP, OpenWatcom), game programmers (Allegro), gamers
(DOSBox), users (FreeDOS, DR-DOS, MS-DOS)
> > It seems that MOSS is using the following "primitives" or syscalls:
>
> It would be interesting to see an actual app running via MOSS
Yup... (Written before you did!)
Hopefully, I finished this post... I'm posting it anyway.
Rod Pemberton
- Raw text -