Mail Archives: djgpp/2009/01/10/00:32:09
Hi,
On Jan 8, 8:36 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:d0ac44e3-772a-44f7-9528-2d6f3f6f1a2c AT h20g2000yqn DOT googlegroups DOT com...
>
> > I don't know what changes between releases of Binutils.
>
> From what I could tell, not much.
Not for us DJGPPers, anyways. But ELF support might've changed a fair
bit since 1996 (GCC G++ 2.7.2 / Binutils 2.6). Heck, the game was
supposedly written mostly in C++, which surely means it would have
some issues with newer G++ versions (e.g. before both ANSI C++ in 1998
or G++ ABI changes around 3.1 etc).
> > I would just use stock DJGPP srcs if I were you.
>
> Next attempt...
>
> FYI, the code for MOSS falls under a bazillion licenses. If one removes the
> FreeBSD directories - assuming they aren't needed - there are like four or
> five or seven licenses.
He did say in the text that some files weren't needed, that this was
just his working directory. So you may not actually need all that.
> The reason I mention that is that it chops up the
> application into many small little files. I reduced it down to just those
> which license the primary parts of the DOS extender, those licensed by
> Ford's software company.
I think he wrote most of this himself "at home" for the game on a
"shoestring budget". The game itself took 24 people (more or less)
over a span of three years.
> I was hoping that since MOSS was small, that those
> files were all that were really needed. Then, I started backfilling in the
> missing pieces. 51 files and counting.... No luck on the low file count.
> My OS has nearly everything he uses, but it's all in a single file. One.
Don't forget that the game itself was targeted at 486s. You obviously
forget how slow a 486 is. So I assume he wanted to be able to compile
quickly (i.e. in little pieces on a multitasking OS) without issue.
It's a lot slower compiling one big file than only compiling the tiny
modified files.
> Since the code pieces are under different licenses, the puzzle pieces can't
> be merged together in a coherent manner. I haven't decided whether I'm
> going to continue the way I'm going, scrap it, or attempt to figure out how
> to compile it "properly"... so I can ignore the stuff that's not needed.
Sounds complicated. I didn't really check into the extender itself,
just the compiler part (which is pretty much stock GCC + Binutils). An
extender which you can't use isn't very useful. But he did provide a
pre-built MOSS.EXE (thankfully!).
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. I
can only guess he did it that way (e.g. used pieces of FreeBSD) in
order to allow commercial use without problems. (Inner Worlds was
shareware / commercial for a while there.)
> > 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
BasicLinux?
> I tried out the IW
> application. Under Win98SE, it "threw a wrench" at my monitor... It
> switched to some mode that wouldn't display. After a reboot, I manually set
> my monitor to the lowest setting - which allowed it to switch properly, it
> would run, halt, run, halt. It ran on DOS nicely. I'm not sure how well it
> would've run on my old 500Mhz machine though.
Before or after installing? The 10 MB .EXE should've unpacked and
created a shortcut or .PIF. And it does sometimes have issues under
other DPMIs (or maybe some select EMS setups), so it's best under real
DOS. At least, it was written for real DOS. Sounds like you didn't
have enough conventional memory free. (See README for some warnings
including that.)
Hard to imagine VGA being incompatible, maybe a driver issue on your
end. Then again, more likely due to not being tested as well on Win9x
(or maybe Windows' driver faults, etc.)
> > I understand all that, just don't know what you're experiencing.
>
> The text is fine. The text alignment is incorrect - due to the missing
> carriage return. Are you familiar with unix2dos or dos2unix utilities?
> What unix2dos does for text files must be done for text output by the C
> compiler so the text is correct for DOS.
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).
> > It works in DOSBox,
>
> If it's correctly emulating DOS, then the text should be shifted like the
> lower picture... ;-)
You're right, of course, but DOSBox isn't really meant to be 100%
accurate, just "good enough".
> > Yeah, I didn't know you were cross posting until I saw that. Fitting
> > to cross post for a cross compiler. ;-)
>
> I thought one of the programmers there might've been interested in a DOS
> project. ;-) Actually, considering they fully implemented a game like that
> in '96, I'd think a few people would be jumping at this. '87 Arcade quality
> 2D when PC's were just getting decent video cards, and low quality 3D DOOM.
> It's too bad the source for the game isn't available.
I'd bet he'd willing to open source (if found), but then again, I'm
not holding my breath.
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)
- Raw text -