Mail Archives: djgpp/2009/01/12/10:30:22
Hi,
On Jan 11, 10:26 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: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 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."
Yes, it can, but you still need to somehow emulate the BIOS and DOS
calls.
> 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.
I've never used 64-bit except for a few trial boots via Linux, but
this is what I've read. I don't think you can switch back to legacy /
compatibility mode without pretty much disabling all 64-bit processes.
You can run 32-bit side-by-side with it, but not 16-bit.
> > > > 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).
>
> 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.
Haven't tried CVS yet, but current DOSBox ain't the fastest thing in
the world. It's good for old games but not for compiling with DJGPP.
Of course, that's beyond its design goals anyways, just saying ....
FYI, you can get latest DOSBox 0.72 on two small-ish Linux distros:
antiX Mepis and CDlinux. I don't know of any including DOSEMU. Then
again, not all even include GCC because "not everybody is a
developer". Well, not everybody wants Firefox / OpenOffice / AbiWord /
Gnumeric on *every single distro* either. Bah, I almost wish there was
a DOSnix distro.
> > 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.
Me either.
> I had problems with Cygwin and MinGW.
They both work pretty well except for minor corner cases (experimental
builds are buggy and MSVCRT's tmpfile() used by "current" MinGW hates
Vista). But I haven't exhaustively tested 'em or anything.
> 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/
Haven't tested all of those, but I do have OpenWatcom installed, it's
quite nice, and the Win32 part works well (although my use of non-DOS
compiling is limited). It's also smaller and static compiles, so
no .DLL issues. But I'm not sure if this supports POSIX at all (doubt
it). But hey, its Win32 compiles also run under HX. :-D
> > 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 rewriting the 32-bit
> DPMI code for 64-bit.
Bigger and more registers is good, but I don't think it helps as
dramatically as marketing execs would like us to believe.
> > Agner Fog's ObjConv
>
> Aware of it, haven't used it. Those who have seem to swear by it.
Try this (2.02, latest is 2.03) DOS port by Japheth if you're curious:
http://www.japheth.de/Download/objconv.ZIP
http://www.japheth.de/Download/objconvs.ZIP
> > 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.
DOS EDIT is way too primitive for my needs, I prefer TDE. I also use
VILE sometimes. Both are compiled by DJGPP, so there are no low memory
limits. If you only use VI for simple things, try sed. ;-)
For hex editing, I use both HIEW and BIEW, but the latter is mostly
better in that it's GPL, compiled by DJGPP, supports up through x86-64
(instead of P3 only), and is optionally also a real to-file
disassembler with opcode coloring for easy compatibility checking.
> 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...
FD Diskcopy works fairly well. And I still use Raread on occasion
(since I think Diskcopy does something Vista doesn't like, e.g.
somehow implies "forbidden" full-screen, meh, I'll have to debug that
eventually).
> > > 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... ;-)
It actually works, so by default that means it's pretty good! ;-)
http://www.geocities.com/dborca/djgpp/elf/djelf.html
Features include:
* ELF executables which run in True Flat mode
* compatible with Linux shared objects
* dynamically loadable libc.so, libm.so, libstdc++.so
* can still link against static libraries (libc.a, ...)
* requires no change to C/C++ code, only minor changes to Asm code
> > 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.
GLIBC seems to only compile with GCC and only for a billion Linuxes
(and GNU Hurd, surprisingly). That alone might make it somewhat
annoying, compatibility-wise.
> > 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)
The DOS community is heavily fractured, and it doesn't always get
along.
And BTW, current Allegro WIP versions dropped DOS support, so stick
with 4.2.2 or whatever if you need it. (Yes, people still use it. I
think RAINE had a DOS compile recently.)
EDIT: Seems Allegro 4.2.2 is buggy in his eyes, so he provides his own
patched version:
http://rainemu.swishparty.co.uk/
P.S. Somebody out there feel free to recompile it and refresh the
online copy:
ftp://ftp.delorie.com/pub/djgpp/beta/v2tk/allegro/all422[ab].zip
(old, buggy)
> Hopefully, I finished this post... I'm posting it anyway.
Cool. :-)
- Raw text -