Mail Archives: djgpp/2009/01/10/11:30:22
"Rugxulo" <rugxulo 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... 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.
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).
> An
> extender which you can't use isn't very useful. But he did provide a
> pre-built MOSS.EXE (thankfully!).
Well, the interesting things to me are:
- moss.exe is different from the moss stub .exe used by the game, setup,
readme
- the moss stub in the game as a standalone .exe will start the a.out or ELF
part of setup.exe and probably readme.exe, but it won't start up the game
which seems to have a bunch more files and a directory...
- 'file' command recognizes the a.out portions of setup.exe and iw.exe as
ELF
- Chris Giese's mbload recognizes the a.out portions as ELF but won't start
them because they load below 1Mb
- 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.
I'm assuming that it uses DPMI under Windows too which might explain the
issues I saw. So, I suspect "raw" mode is what works well.
- the point above means that of the supported startup modes (DPMI, EMS,
VCPI, or raw) that raw is working, but DPMI isn't quite.
- Daniel Borca doesn't seem to have an ELF DPMI startup... (?) I' haven't
looked into how his library or executable startup was setup without it.
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...
> 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.
> > > Recompiling MOSS.EXE doesn't give you any examples, so in order to
> > > test it, I had to find a way to build.
> >
> > 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.
> I tried real MS-DOS, DR-DOS, and FreeDOS. You're right, it does have
> that issue with text not wrapping correctly. That's just a minor nit,
> IMHO. You can always pipe it to something else (esp. w/ *nix LF
> support) without issue. Obviously he was less interested in text mode
> than making his game (gfx, sound, joystick / gravis, etc).
If there is ever a completed port, it'll be fixed then. I've considered a
DOS TSR to convert them just so I can use DOS' "type" on *nix files... It's
just a minor nuisance with *nix files. Personally, I don't like the fact
that DJGPP uses CRLF. I'd prefer to have the compiler just us LF like *nix
and use conversion programs or a TSR to correct. Using two characters
instead of one in C to represent an EOL, complicates much of C's text
abilities and ASCII text processing. Because of this, I always use binary
mode with adjustments to avoid text mode.
> 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.
> 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.
Rod Pemberton
- Raw text -