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: Thu, 8 Jan 2009 15:28:21 -0800 (PST) Organization: http://groups.google.com Lines: 247 Message-ID: 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 1231457301 31060 127.0.0.1 (8 Jan 2009 23:28:21 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Thu, 8 Jan 2009 23:28:21 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: h20g2000yqn.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 n08NU7hn010258 Reply-To: djgpp AT delorie DOT com Hi again, :-) On Jan 8, 3:24 pm, "Rod Pemberton" wrote: > "Rugxulo" wrote in message > > news:886d17b9-399f-48ed-ac4d-45ca11d3879f AT s20g2000yqh DOT googlegroups DOT com... > > > The only problem I had is due to inexperience: I don't know how to > > organize the actual compiler install to correctly work without -I and - > > L hacks (i.e. I didn't want to make a C:\USR\LOCAL dir just to hope > > it'd work). I mean, I'm wondering can you install it similar to a > > default DJGPP install (C:\DJGPP\BIN, LIB, INCLUDE, etc.) or do you > > have to run it like "..\i386-moss\i386-moss-gcc" ?? I'm sure somebody > > knows, they're probably just too lazy^H^H^H^H busy.    ;-) > > It seems Binutils 2.19 supports moss as does GCC upto 3.3.6.  So, you should > be able to build new enough versions to be useful. 3.4.x introduced optimizations for the Pentium4, I think. It's also slower than 3.2.3 (which has some C99). And 2.95.3 supports PPro but was the last of its branch (combined EGCS + GNU). And 3.0.2 etc. is much bigger in size and slower. (2.96 was an unofficial patch by Red Hat.) As you know, 2.8.1 was the first official GNU version to support 586 optimizations (since 2.7.2.1 was 486 only). Okay, enough history lesson! :-) I don't know what changes between releases of Binutils. Reading the changelog a while back was unimpressive. At least for us (DOS / COFF) I don't think anything has changed in a while. And I'm not using MMX or SSE for this or rebuilding latest GCC, so I'm less interested in newest. (Those probably take a lot longer to compile, too.) For this I just used stock BinUtils srcs 2.10.1 from GNU since I don't think DJ archives all old versions (e.g. no srcs for older than 2.15 in either / current/ or /beta/). EDIT: Actually, DJ's ftp seems to have older in /deleted/ (e.g. bnu27 [bs], bnu2951[bs], etc). bnu2951.README says MMX, SSE, and 3dnow! are supported (and, surprisingly, claims to not need LFN environment to compile). In any case, I wanted something lean, small, and fast as well as old enough to hopefully work but new enough to be useful. It's not that I need Pentium-specific optimizations, but too old means new code won't work (and vice versa). Oh, BTW, when was it that ".intel_syntax" was added, 2.9? That is indeed worth having. :-)) This also means the little assembly MOSS uses is AT&T (yuck). OFFTOPIC: For instance, I recompiled GCC 2.95.3 and BinUtils 2.16.1 via "-Os" recently with the goal of producing a small 2.03p2-based compiler that would fit on a floppy compressed. Anything older is too moldy for my tastes, and anything newer is too big to fit. (7zdec compiled by OpenWatcom comes in handy here. I have not yet released the .7z on my site, though, still barely tweaking it, but it's done and unpacks in lots less RAM now.) This was intended to be an EZ-GCC for v2 (although I never tried v1, my first GCC was 2.7.2.1 and DJGPP 2.01? on my 486 in 1997, brrrr, compiling Allegro back then was kinda slow, and actually 2.95.3 ain't any faster, but it's faster than 3.x or 4.x, that's for sure.) > But, I'm having problems.  Neither DJGPP 3.4.1 nor 3.3.6 would cross-compile > stock GCC 3.3.6 failing in the middle of compiling gcc.c complaining about > an assignments to a read-only variable.  Perhaps, I should try DJGPP GCC 3.3.6 > compiling DJGPP GCC 3.3.6 as a cross-compile, but I thought the code for GCC > hadn't been changed for DJGPP...   I did use the stock DJGPP srcs for GCC 2.95.3, but I dunno if it matters. Look for a \BUILD.DJG subdir with DJCONFIG.SH. I think I modified it (barely) and then ran that. That may be your problem if you're trying to run "configure" manually. You may also not have all the tools it needs (cp, mv, sed). Also, GCC is pretty annoying in that you do need specific versions to compile itself. As mentioned, try GCC 3.4.4 if later doesn't work. (I still say I could e-mail it to you. But that path setup issue is so annoying! Anyways ....) Comparing files djconfig.sh~ and DJCONFIG.SH ***** djconfig.sh~ export CONFIG_SHELL=bash dft_target=i586-pc-msdosdjgpp # ***** DJCONFIG.SH export CONFIG_SHELL=bash dft_target=i386-pc-moss # ***** ***** djconfig.sh~ # $srcdir/configure --srcdir=$srcdir --disable-shared --verbose \ --with-gxx-include-dir=\\\${prefix}/lang/cxx \ --with-gnu-ld --target=${target-${dft_target}} \ --host=${target-${dft_target}} \ --prefix=\\\$\$DJDIR ***** DJCONFIG.SH # $srcdir/configure --srcdir=$srcdir --verbose \ --with-gnu-ld --target=${target-${dft_target}} \ --host=i586-pc-msdosdjgpp \ --prefix=\\\$\$DJDIR ***** I doubt the whole i386/i586 part makes a difference, but I did it anyways. And I only wanted C, no C++, so I wiped that line and used "sh djmake.sh LANGUAGES=c". BTW, I really suck at recompiling GCC, so I don't honestly know what I'm doing. Or maybe it's that newer GCC has trouble with older srcs, I dunno. In any event, I never got LIBGCC.A to recompile, so I just used the original (old) one from the Linux cross compiler (is that bad? is that wrong? seems to work, at least, and I dunno what else to do). > Binutils fails near the end of make with > error 2.  I know from past experience, that once everything is working > correctly, those mysteriously go away.  This is one reason why I prefer to > always have binaries, but be able to get source instead of the GNU it's > always source, and never binaries model.  Even if the code won't compile > anymore, the executable will work. Yes, pre-built binaries are good. Of course, -static helps a lot too, but GNU/Linux has some severe problems with bloat there (i.e. NetBSD or Minix aren't nearly as big), dunno why (NLS? reentrancy?). > > Anyways, I could always just e-mail you the binaries I compiled > > I'd rather get it to work on my machine.  I've experienced similar problems > trying to cross-build with DJGPP in the past. There's probably a cross-build mailing list we could ask. I did briefly e-mail Bryan (Ford) with a pretty wimpy "Hi, how's it going?" just to see if he was still around (no response yet). That's a long shot, though, I doubt he's still interested. > > > If I can compile it, it should be easier to port or at > > > least get the code to compile on newer versions. I'm not saying I can get > > > it working or anything, just that I'll look into it. > > > I know, no pressure. It was all your idea anyways. Only try to have > > some fun with it.  ;-) > > Sorry, for some reason, I was thinking you compiled moss.exe...  Actually, > with the size of moss.exe being so small, I can't imagine all of the code he > included actually being used.  It's just a matter of determining what was > used, since I'm not sure that it'll ever compile again in it's current form. Recompiling MOSS.EXE doesn't give you any examples, so in order to test it, I had to find a way to build. Of course, not sure which is easier / better: DOS host or old BasicLinux w/ precompiled 2.7.2 / 2.6. Obviously I'm biased towards the former, but at least the latter installs on top of DOS and is very lean. > > You can ask > > ./configure --target=i386-moss > > ./configure --target=i386-moss --host=i386-pc-msdosdjgpp --build=i386-pc-msd > osdjgpp > > What did you use or do?  But, I think I might be using the wrong set of > sources: stock GNU instead of DJGPP. I dunno, does stock have BUILD.DJG\djconfig.sh? (GCC's SVN doesn't have it or else I can't find it.) I would just use stock DJGPP srcs if I were you. > > > The MOSS version runs under MS-DOS v7.10, but has "'\n' -> '\r\n' > issues." > > > I have no idea what that means. > > Ah, I quoted what you quoted.  DOS uses both an ASCII carriage return (CR or > \r) and linefeed (LF or \n) to move to the beginning of the next line.  LF > in DOS moves down a line.  CR moves to the begining of the line.  *NIX > usually uses just LF to do both.  Mac's use just CR to do both.  This was a > historical misunderstanding with early ASCII.  DJGPP fixes this behind the > scenes.  So, when text just using LF is displayed, it moves down a line, but > not to the start of the line.  The text shows up as a staggered and > wrap-around look.  Think stack of domino's versus stack of domino's with a > tilt. I understand all that, just don't know what you're experiencing. Is the text showing up on the screen incorrectly or being unpacked by 7ZDEC incorrectly or something else? It works in DOSBox, still haven't tested on real hardware yet. (QEMU + FreeDOS seems to imply that HIMEMX or JEMM386 won't work but others seem fine, go figure.) > > Atari Lynx > > What?  I thought you were younger than that...  ;) I'm 29. I never had a Lynx "back in the day" for whatever reason, but it had some cool arcade ports. I even bought a used Lynx 2 on eBay a few years ago (2004?) with games, but it eventually crapped out in 2006 or so (screen stopped working). That's what I get for buying electronics made in 1991 !! > >http://www.brynosaurus.com/ > > I didn't realize he worked on vx32 also...  I've read the papers and looked > it over a few times.  It, like many other open projects, has some features I > like, but it isn't as developed as much as I'd like or going in the > direction I'd like.  In the case of vx32, they just do binary translation to > implement their sandbox.  But, with more development, vx32 could be used as > an x86 emulator, possibly with much better performance than others. It claims security, fast speed (even SSE supported), and portability. He says, "porting to Windows XP should be possible", which would of course be very very interesting. (Of course, they also intended to port Inner Worlds to Windows 2000/NT/ME "eventually", and that never happened.) At least the idea that FreeBSD, Linux, Linux 64-bit, Mac OS X all work sounds pretty cool. > > P.P.S. Sebastien, you cross-posted to the wrong group!    :-P > > I threw on comp.os.msdos.programmer.  He posted to the wrong thread there. > His response was to Herbert Kleebauer in "Adding equal sign as a parameter." Yeah, I didn't know you were cross posting until I saw that. Fitting to cross post for a cross compiler. ;-) BTW, the ELF output from MOSS doesn't run under BasicLinux, which I vaguely hoped it would. Oh well, can't have it all.