X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Rugxulo <rugxulo AT gmail DOT com>
Newsgroups: comp.os.msdos.djgpp,comp.os.msdos.programmer
Subject: Re: TRYING TO MAKE EXE RUN ON FRIENDS MACHINE
Date: Sat, 10 Jan 2009 13:36:27 -0800 (PST)
Organization: http://groups.google.com
Lines: 172
Message-ID: <59d15676-685a-4ad8-a43a-7715035abbaa@f3g2000yqf.googlegroups.com>
References: <cc2668db-926c-41e1-9836-5a42a1210ed6 AT s9g2000prg DOT googlegroups DOT com> 
	<uwsdcmjo7 DOT fsf AT gnu DOT org> <5fb78e93-bed6-46d9-85c8-a838e35b3d22 AT r36g2000prf DOT googlegroups DOT com> 
	<uprj4mbv6 DOT fsf AT gnu DOT org> <9941ccce-87a6-4ace-9f78-9b15710643bd AT x8g2000yqk DOT googlegroups DOT com> 
	<gjve0m$2rt$1 AT news DOT tornevall DOT net> <4563e62e-7382-4c6a-b986-d4c8a8ff9d47 AT i18g2000prf DOT googlegroups DOT com> 
	<0541cc98-689c-4e6c-ae02-d6f5a1b4a9cb AT l37g2000vba DOT googlegroups DOT com> 
	<gk54mb$i0$1 AT news DOT tornevall DOT net> <886d17b9-399f-48ed-ac4d-45ca11d3879f AT s20g2000yqh DOT googlegroups DOT com> 
	<gk5qld$euh$1 AT news DOT tornevall DOT net> <d0ac44e3-772a-44f7-9528-2d6f3f6f1a2c AT h20g2000yqn DOT googlegroups DOT com> 
	<gk6cuo$qor$1 AT news DOT tornevall DOT net> <eec87f79-da47-45ca-9f26-b55dc37ba7ab AT e3g2000vbe DOT googlegroups DOT com> 
	<gkahb5$ecb$1 AT news DOT tornevall DOT net>
NNTP-Posting-Host: 65.13.115.246
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1231623388 17335 127.0.0.1 (10 Jan 2009 21:36:28 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Sat, 10 Jan 2009 21:36:28 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: f3g2000yqf.googlegroups.com; posting-host=65.13.115.246; 
	posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) 
	Gecko/2008120122 Firefox/3.0.5,gzip(gfe),gzip(gfe)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id n0ALj63i029537
Reply-To: djgpp AT delorie DOT com

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.)