X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo 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: <5fb78e93-bed6-46d9-85c8-a838e35b3d22 AT r36g2000prf DOT googlegroups DOT com> <9941ccce-87a6-4ace-9f78-9b15710643bd AT x8g2000yqk DOT googlegroups DOT com> <4563e62e-7382-4c6a-b986-d4c8a8ff9d47 AT i18g2000prf DOT googlegroups DOT com> <0541cc98-689c-4e6c-ae02-d6f5a1b4a9cb AT l37g2000vba DOT googlegroups DOT com> <886d17b9-399f-48ed-ac4d-45ca11d3879f AT s20g2000yqh DOT googlegroups DOT com> 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" wrote: > "Rugxulo" 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.)