delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2009/01/12/03:45:05

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: Jim Michaels <jmichae3 AT yahoo DOT com>
Newsgroups: comp.os.msdos.djgpp,comp.os.msdos.programmer
Subject: Re: TRYING TO MAKE EXE RUN ON FRIENDS MACHINE
Date: Mon, 12 Jan 2009 00:41:25 -0800 (PST)
Organization: http://groups.google.com
Lines: 50
Message-ID: <e0659e0d-3547-4f41-aa48-1f16b1dd69a7@f40g2000pri.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: 76.115.70.155
Mime-Version: 1.0
X-Trace: posting.google.com 1231749685 9973 127.0.0.1 (12 Jan 2009 08:41:25 GMT)
X-Complaints-To: groups-abuse AT google DOT com
NNTP-Posting-Date: Mon, 12 Jan 2009 08:41:25 +0000 (UTC)
Complaints-To: groups-abuse AT google DOT com
Injection-Info: f40g2000pri.googlegroups.com; posting-host=76.115.70.155;
posting-account=05hOMwoAAAB6R8xtiQKzEljSMzgOhVF1
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 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 n0C8j4HT003906
Reply-To: djgpp AT delorie DOT com

> > The stub is 16-bit,
> You could unstub...
> > and the C lib does call BIOS and MS-DOS interrupts
> ... but you can't fix that easily.
> > I don't know how to combine a DJGPP + Win32 .EXE, though. Anyways, for
> > building on Windows I would suggest Cygwin (unless your app must be
> > closed src, which I think Cygwin forbids by default), esp. since you
> > can also optionally get the MinGW runtime support so you can compile
> > for either (and Cygwin uses its own .DLL and doesn't use buggy MSVCRT
> > but is *allegedly* slower). 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.  Since I don't have a Linux box here
> with 64-bit GAS, the guy didn't get a reply from me...  So, I'd like to see
> some "new" and "non-DOS" features enabled in DJGPP, even if they can't be
> used for DOS, or by anyone yet due to bugs or incompletenees, etc.  ELF
> support in binutils and an ELF target, perhaps "i386-elf" or
> "i386-generic-ELF", would help OS developers who are using DJGPP.  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.  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.


I would really like to see a gcc compiler for the windows platform.
Windows has a POSIX subsystem. I would like something that doesn't
make me use a DLL like cygwin.  Besides, cygwin has dll versioning
problems.  I want monolithic executeables.
I would also like to see a name change for the pdcurses library.  The
name should be something more like what it does, like cursorxy, which
happens to fit in 8 characters.
Jim Michaels

- Raw text -


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