delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2009/01/07/12:01:41

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: 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: <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>
NNTP-Posting-Host: 65.13.115.246
Mime-Version: 1.0
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
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" <do_not_h DOT  DOT  DOT  AT nohavenot DOT cmm> wrote:
> "Rugxulo" <rugx DOT  DOT  DOT  AT gmail DOT com> 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.   ;-)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019