Mail Archives: djgpp/2009/01/10/16:45:46
Hi,
On Jan 10, 10:16 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
> news:eec87f79-da47-45ca-9f26-b55dc37ba7ab AT e3g2000vbe DOT googlegroups DOT com...
>
> > I didn't really check into the extender itself,
> > just the compiler part (which is pretty much stock GCC + Binutils).
>
> Yeah, that's what I thought in regards to the C library too. I.e., I was
> thinking he was using pretty much stock GLIBC/LIBC, but he's using all those
> FreeBSD files for the C library...
If he used GLIBC, it would've be v1 anyways (which was forked to
become Linux's libc5), which is too old to be useful these days. At
least current version (2.9) is apparently LGPL.
From what I can tell, there are other C libs for Linux too, e.g.
Newlib, Dietlibc, etc., which may prove more useful, I dunno.
> So, porting or conversion to GLIBC/LIBC
> needs to be done too. I think the 'moss' directory is the front end of
> moss.exe. The 'mach4-i386' are the low-level parts of moss.exe. I'm not
> sure if the 'mach4' directory is being used much. The 'freebsd' directory
> is the custom C library.
As mentioned, I think I saw somewhere that he called it "Mach on DOS",
aka MOSS, so it may indeed use some Mach stuff. But it's really just a
snapshot of his work directory, so some stuff isn't needed.
> On the other hand, since the patches to support "i386-moss" don't do much
> and moss.exe starts up an ELF a.out, it might be possible to use another
> target, i.e., "i386-generic-ELF," which is supported by more recent GCC and
> Binutils. The good news in regard to the library is that he was only using
> the handful of calls I mentioned previously (if I didn't make a mistake).
What's the difference (or advantage) to using generic ELF instead of
what's currently used?
> - both moss.exe and the moss stub will start in DOS under a DPMI host, like
> CWSDPMI, but fail to run the a.out part of setup.exe or the game. They fail
> with either a paging allocation issue or or a failed memory locking call.
It does seem to whine a lot under another DPMI host, but at least my
7zdec example seemed to still run there in some cases. (Didn't it say
"paging = 4096", so he was using 4 MB pages?? Maybe that's the
problem. CWS says 4 MB pages aren't supported under VCPI or DPMI 1.0.)
> I'm assuming that it uses DPMI under Windows too which might explain the
> issues I saw.
It supports the big four like most modern extenders: DPMI, VCPI,
XMS, raw. Obviously Windows won't allow raw or even VCPI (except e.g.
Win 3.1 /S "standard" mode). And Windows does eat up lots of RAM for
itself too.
> So, I suspect "raw" mode is what works well.
It works well in other setups too, e.g. some XMS or some VCPI. At
least, it didn't have any problems under MS-DOS 6.22 HIMEM + EMM386
(or DR-DOS 7.03), only whines a bit under Win 3.1 (but still seemed to
work).
> - the point above means that of the supported startup modes (DPMI, EMS,
> VCPI, or raw) that raw is working, but DPMI isn't quite.
I do think his DPMI support needs improvement, most likely, but I
wouldn't think that "raw" is the only other way of working. Especially
since "raw" isn't really practically used for anything. It just has
some compatibility issues with some (not all) newer software that
didn't exist back then.
> The good news is I understand the DPMI mode code for moss.exe. The bad news
> is that we probably want raw mode code since it seems to be what is working
> the best. I was looking into porting just the DPMI portion to DJGPP and/or
> OpenWatcom. But, if the DPMI startup isn't functional, as I found, that
> makes it less likely to work...
As mentioned, it's not totally broken, just quirky. I'm sure it could
be fixed. I definitely wouldn't prefer to use raw exclusively, and I'm
pretty sure you don't have to.
> > At least, I can't imagine he'd release it if the licenses conflicted,
> > esp. if he was going to declare it GPL and use GPL compiler tools.
>
> Well, the parts of moss.exe for the DPMI are either GPL or (I think) the
> functionality is already in DJGPP. So, the non-GPL parts could possibly be
> removed or rewritten.
I'm not as worried about that as you are (esp. since I'm not a lawyer
and don't understand most licenses anyways).
> > > If you manage to recompile moss.exe, let me know.
>
> > Did you try the pre-built Linux GCC 2.7.2 cross-compiler under
>
> No, I haven't setup any Linux machines. I'd use QEMU, but I don't know how
> to transfer files between the QEMU image and my OS. Since this machine
> boots USB, I was thinking about buying a larger USB flash drive to setup
> Linux with multiple versions of GCC/binutils/LIBC/GLIBC to give me an idea
> of how it builds, to allow me to progressly recompile to a newer compiler
> and library, etc.
You're using Win98 and can boot to DOS mode, so just unzip BasicLinux
on top of your FAT partition. It's only 20 MB unpacked, so it's not
much (only 4 MB or so .ZIP'd). Then just unpack the prebuilt Linux GCC
cross-compiler on top of that: "cd / ; tar xvzf /tmp/moss-0.90-bin-
linux.tar.gz ; export PATH=/usr/local/i386-moss/bin:$PATH"
I don't think QEMU does share files (although there is some
experimental USB crud that I never tried). At least it won't write,
but it can read from host OS:
qemu -m 128 -L . -fda myflop.img -hda myhard.img fat:/armslurp/moss -
boot a
This will boot from floppy, use myhard.img as C:\ (or /dev/hda1 or
whatever) and use \Armslurp\MOSS as D:\ (or /dev/hda2 or whatever).
Then you can copy the files to a writable location (e.g. /tmp) and
edit them there. Of course, if you need to transfer back to your host
OS, you either have to do some FTP trickery or write to myflop.img and
use an extract tool (which is what I typically do). Or even e-mail
yourself if the guest OS supports networking. ;-)
> > I'd bet he'd willing to open source (if found), but then again, I'm
> > not holding my breath.
>
> It'd be nice, but the game isn't important. The additions/changes to the
> library and moss.exe might be useful.
Just seeing some examples as well as supposedly portable code would be
interesting and useful. The game itself is probably pretty huge
although most likely the data itself takes up way more space than the
executable stuff.
> > P.S. Found another thing DOSEMU supposedly needs: Glibc 2.2 (and
> > just so you know, Eric Auer couldn't get IW to run under that yet)
>
> Download the U7Win9x extender and read what they had to do to get Ultima 7
> to work on Windows... It used "Voodoo mode", aka unreal or bigreal mode.
http://members.iinet.net.au/~rsd/five.html
No surprise they had issues. Last I heard, even BOCHS didn't support
unreal (nor DOSBox either). Hence DPMI was added to FASM (although he
claims to use "flat real mode", but I think it's pretty much the same
thing). Sad that the whole point of DPMI was Windows compatibility
(right?), and yet Windows has had so many issues with it over time.
Old Cyrix chips (e.g. early 586s or whatever) couldn't even use unreal
mode, which is yet another blow to such a weirdly useful hack. Still,
is it really that big an advantage over normal coding methods? (Maybe
for speed or easy access to hardware, I dunno.)
- Raw text -