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: Wed, 7 Jan 2009 08:53:30 -0800 (PST) Organization: http://groups.google.com Lines: 163 Message-ID: <4563e62e-7382-4c6a-b986-d4c8a8ff9d47@i18g2000prf.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> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1231347210 16252 127.0.0.1 (7 Jan 2009 16:53:30 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Wed, 7 Jan 2009 16:53:30 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: i18g2000prf.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 n07H07S5005762 Reply-To: djgpp AT delorie DOT com Hi, On Jan 6, 5:11 am, "Rod Pemberton" wrote: > "Rugxulo" wrote in message > > Well, another good post Rugxulo. Let's go for 2/2. :-) > > The latest > > DOSEMU for GNU/Linux emulates the 16-bit stuff under 64-bit mode, > > I think the best solution would be DOSEMU ported to Vista, using FreeDOS as > the required DOS.  IIRC, the latest DOSEMU builds using libSDL, so I'd think > this is doable, if not already done... DOSEMU also needs S-Lang2, IIRC. But I have no idea when DOSEMU was or ever will be compiled for Windows. > > The stub is 16-bit, > > You could unstub... Sure, but I see no advantage there. > > and the C lib does call BIOS and MS-DOS interrupts > > ... but you can't fix that easily. It can't be that hard. I mean, people write JIT compilers and VMs all the time (e.g. Ruby or Perl). > > Cygwin has lots of ports of stuff, so you > > can't really go wrong there (right, DJ?).    ;-) > > Yeah, DJGPP is "dying"...  Like, the other day, I needed to assemble and > disassemble some 64-bit GAS code to reply to a newsgroup post, but 64-bit > code was disabled in DJGPP's binutils. Cygwin and MinGW aren't exactly perfect either, still stuck to old versions due to .DLL and exception issues (as well as the always- problematic lack of maintainers). Anyways, there have been a (very) few attempts at a 64-bit DOS extender, but they're mostly proof of concept and don't do anything (or even return cleanly). Hence 64-bit is less interesting to DOS users (esp. no V86 mode). But there are DOS ports of certain tools that support it. (Good luck building a DJGPP cross-compiler for it! GCC is kinda complex / annoying to rebuild.) At the very least are Agner Fog's ObjConv and Nick Kurshev's BIEW, both of which have DOS ports. I'm not aware of other 64-bit tools (besides NASM, FASM, YASM, obviously). > ELF support in binutils and an ELF target, perhaps "i386-elf" or > "i386-generic-ELF", would help OS developers who are using DJGPP.   But there was a COFF bootloader at one time, right? (I know you know more than me on this since I don't write OSes, heh.) But yeah, ELF is pretty ubiquitous, so having some support in DJGPP can't hurt. > Of course, I'd expect code produced for the ELF target to be pure 32-bit or > 64-bit, even if non-functional...  I'd prefer that the split memory model, > i.e., application address space and below 1Mb, be kept.  At some point, I'd > like to see the standard GLIBC used for DJGPP.  This would require much of > DJGPP's POSIX and LFN related libc code patched "underneath" GLIBC.  This > would improve software compatibility, reduce porting issues, keep GNU > utilities current, etc., although it'd eliminate much of "DJGPP" itself. It would only optionally replace it. Remember that the DJGPP/ELF third- party experimental hack kept both COFF and ELF support. (And boy, - static ELF is much bigger than COFF, sheesh. WTF?!) > If a suitable compile target is available, this "compatibility layer" might be > doable entirely in the DOS DPMI host and/or 16-bit .exe stub, allowing use > of completely stock GLIBC.  There is some history to support that this is > possible, see the MOSS DPMI host: > > http://www.cs.utah.edu/flux/moss/moss.html = "Mach on DOS" (Bryan Ford) = GPL, compiles fully with GPL tools, uses subset of FreeBSD libs so free for almost any use = not updated since 1996 = (old) Linux binaries (GCC 2.7.2) are dynamically linked (doh), don't run on Slackware 11 = no real-world examples anywhere (or at least I couldn't find 'em) = currently no (obvious, automatic) way to bind .EXE and a.out ELF file into one (although possible) = GCC 3.3 (and similar timeframe BinUtils) still had (leftover) support for it, but I dunno after that > Since it seems MOSS uses an *almost* stock GCC and GLIBC, I'd think a port > of MOSS to DJGPP might help in creating a complete, stock GCC and GLIBC > combination that works on DOS MOSS might be too minimal for GLIBC, and some things are pretty hard to port. Or at least, people with the *nix mindset have a hard time (apparently), even if they are willing (which they usually aren't). :-/ I've heard it said that DOS is only viable for games, but nobody seems to be writing many of those anymore. Maybe just a subset of GLIBC would prove worthwhile, but I'm not qualified. :-( > I'd suggest removing any code that might > bypass DJGPP, e.g., the Flux OS toolkit code.  I think MOSS might run on > other DOS DPMI hosts like CWSDPMI, so I'd probably remove VCPI, EMS, and any > unecessary DPMI, etc. code.  Then, the MOSS DOS extender will compile as a > standard DJGPP application, it would then use CWSDPMI and DJGPP's POSIX and > LFN's, etc. which are probably more up to date and likely have fewer errors. Assuming you want to recompile all of that "POSIX and LFN's" for ELF (which will break a few things, e.g. unexec). > Since MOSS.EXE is 38k, the resulting "conversion layer" after coreing should > be very small, perhaps small enough that it could be added to CWSDPMI.   MOSS.EXE is limited to 64k (although they claim they knew how to overcome it but never mentioned, only pointed to now-nonexisting mailing list), so 38k + 20k for CWSDPMI = pretty close to the limit (tight assembly probably needed). > It seems that MOSS is using the following "primitives" or syscalls: It would be interesting to see an actual app running via MOSS, but that requires rebuilding the toolset (which I failed at doing last night, blech). At least MOSS.EXE comes precompiled, but it didn't like the ELF .o that DJGPP/ELF made, so .... > MOSS has C wrappers to call the following DPMI functions.  It doesn't use > five or so of them.  Three are DPMI 1.0, but only two are used.  Of the DPMI > 1.0 calls, one is supported by CWSDPMI and one isn't: Although I think they should speak for themselves, I heavily suspect CWS is too busy / disinterested. Same for DJ. There aren't a lot of qualified DPMI authors anymore. > 1687 (2f), 0, 6, 7, 8, A, B, C, D, 202, 203, 204, 205, 300, 400, 501, 502, > 504, 505, 509, 600, 601, 604 You know way more about DPMI than I do, so surely you know how hard it is. ;-)